Aircraft crashed due to wrong take-off performance

[BoeingBobby]

If you are losing acceleration before V1 you need to abort.

Please educate me on how and where this system will be installed and implemented.

[Gabriel]

The beauty of all of this is that it's a very classic Engineer - Pilot argument that goes waaaaay back.

I don't agree.

Acceleration during take-off is an important information for the pilot. Most of the times not for us little plane pilots that take off from RWY that are quite longer than minimum needed. But in airliners, many times the plane is loaded up to the point that the take-off performance is RWY limited, and if it happens that the TOW is low and the take off would not be RWY limited, then they use an assumed temp to reduce the TO thrust to the point that the take-off becomes RWY limited.

In those conditions, a 20 or even 10% less acceleration than the take-off computation assumed, could be critical. And it would be very hard for the pilot to tell if that's the case, because the human body is not so good at measuring acceleration, and because from one take-off to the next the acceleration, even if it's the expected one, can differ in more than that, so the pilot doesn't even know the expected acceleration to begin with.

Now, you can make it a full blown TOPMS linked to the FBW and the ELACs and SECs and HAL and synthesized voice... or you can just display the acceleration (which is already done in many planes, as an airspeed trend in the PFD) together with a mark or bug for the expected value, and make it a SOP for the PF or PM to check it on the 80 kts call.

At that point of the discussion, we can get into an eng vs pilot discussion. But we are not even there yet. Rather discussing if something else than what's available now is needed or not.

And again, we can discuss at length if it is needed or not, and what would be the best way to implement it. Just make it your argument vs my argument, not your credentials vs my credentials.

[Gabriel]

There are many options, and I am saying this for the third time in the thread only.

The simplest one would be to display the airspeed trend (which is already done in many planes) together with a mark or bug for the expected acceleration.

But first of all, do you agree that if you are losing acceleration before V1 you need to abort? That is either an engine failure (maybe partial failure, but failure) or something else going really bad and dragging your plane back. It could also be a blown tire, which would not warrant a a high speed abort, but my understanding (not much in this case) is that a blown tire will have a minimum impact on the acceleration (but it will have a stronger impact on the braking capacity, hence not a good idea to abort a high speed)

[BoeingBobby]

There are many options, and I am saying this for the third time in the thread only.

The simplest one would be to display the airspeed trend (which is already done in many planes) together with a mark or bug for the expected acceleration.

Well like I said in one of my previous posts, there is already a clock with a sweep second hand. And in the new gen there is a stop clock in the PFD. A/S bugs work on the old round dials and there is already one in the PFD that we set for V2. To you propose a second bug that is also set? And what would you set it to?

[3WE]

If you are losing acceleration before V1 you need to abort.

Yes...that was my point. Evan said that TOPMS would alert you WELL BEFORE V1...(Which yeah, it should if you are having acceleration problems well before V1)

But not_all acceleration problems occur well before V1...some could occur shortly before V1.

IF (and that's a big IF) we enact such a system, something makes me think it will monitor and provide alerts right up to V1...

...or maybe it should provide alerts all the way to V3BS, the velocity at which you could run off the end and have a hopefully-survivable crash? Yes, I think that is also a good idea.

[Gabriel]

Well like I said in one of my previous posts, there is already a clock with a sweep second hand. And in the new gen there is a stop clock in the PFD. A/S bugs work on the old round dials and there is already one in the PFD that we set for V2. To you propose a second bug that is also set? And what would you set it to?

This bug would be for the airspeed trend (the vertical green arrow in the airspeed bar in the photo below, although during take-off it will be pointing up), not the airspeed itself. Unlike the airspeed and its bugs, both the airspeed trend and its bug will be pretty much static along the take-off run.



The bug would be the expected acceleration given the take-off parameters assumed during the take-off computation. I know that different parameters like runway length, slope and condition, length of any stopway or clearway, distance and elevation of obstacles along the take-off and initial climb path, airplane weight and CG, avilability of equipment (like anti skid), wind, QNH, tamp, etc... are used to dcide if the packs will be on or off during take-off, the take-off flaps, the take-off trim, the take-off thrust (or assumed temp) and the Vee speeds (V1, Vr, V2). I don't know how is the procedure done, though, Depending on that, the bug can be automatic (hopefully) or can be set manually (it would be a new output parameter of the take-off computation). Take into account that that expected acceleration already exists. Just that it is not known to you the pilot, but it is an integral part of the take-off performance calculation (and is different for every take-off).

Now, if by mistake you did the take-off calculation with 129350 lb instead of 192350 (a stupid honest mistake that is hard to catch once made), you will get a slower set of Vee speeds and a lower thrust setting (higher assumed temp) because the computation thinks that the plane will accelerate faster (due to its lower mass) so it will achieve take-off speed (say Vr) in less runway run, and that said take-off speed is slower anyway because the wight is low, so again less runway is needed.

If you execute that take-off, you'll have the plane accelerating slower, achieving the computed Vr much farther down the runway, and even if you reach that Vr within the runway the plane will not lift off because that Vr is insufficient (if the runway is long enough, you will take off, eventually, when you are going much faster)

However, the speed trend will also be much lower that the same take-off computation expected. It expected the plane to accelerate faster because it was supposedly light. If we have a bog on the expected acceleration and we see the airspeed trend below that bug, we can abort while still at slow speed (like 80 knots, which is a nice speed to do the check because both the PM and PF have to look at the airspeed indicator at that point anyway). You only need the engines thrust stabilized to make a valid comparison (if the engines are still spooling up of course the acceleration will be lower, that's why this will not work in the first few seconds of the take-off run).

[3WE]

...[Gabriel's proposal of what we should do]...

***AND***

Why don't we also have the airspeed depicted as green, yellow (*5% deficient) and red (*10% deficient)...yellow would mean look CLOSER at the bug, and evaluate everything with an increased scrutiny being really ready to abort if you find a good reason OR it turns red.

*5% and 10% numbers pulled from my rearward areas...no doubt Evan or Gabriel might have a more logical number.

***AND***I still think we want this to operate up to V3BS, right?

[Evan]

It takes very little imagination to come up with potential mechanisms to lose acceleration at higher speeds (closer to V1) so TOPMS is gonna be monitoring and might just spit out a false warning if a swarm of dragonflies smacks the pitot tubes.

And then what? You pull back the thrust levers and autobrake. There you are, safely on the ground, maybe on the rims, possibly in the grass. Versus nested in the approach lights in various pieces.

Again you avoid the question. What is the horrible scenario you speak of?

Airport (Joe Patroni getting a 707 un stuck)

I have to hand it to you, this is a stellar example of the cigar-chomping gut instinct improvisation vs. engineering. The scene where he drives the 707 out the snowbank with engine thrust is classic this. They must have edited out the part where some time in the future that same 707 suffers a gear collapse due to damage from the stress old Patroni put on it...............................

[Evan]

[ATTACH=CONFIG]6736[/ATTACH]

In this example, the TOPMS alert would be "bank angle bank angle"...

[Gabriel]

In this example, the TOPMS alert would be "bank angle bank angle"...

Not to mention that in 6 seconds they will be stalling...

[3WE]

And then what? You pull back the thrust levers and autobrake. There you are, safely on the ground, maybe on the rims, possibly in the grass. Versus nested in the approach lights in various pieces.

Again you avoid the question. What is the horrible scenario you speak of?

Aborting very close to V1 and the idiot pilots you like to throw under the airbus.

I seem to have recently read somewhere that emergencies near V1 are kind of a big deal and that they've been FUBAR'd a time or two and broken a number of light bulbs.

Maybe even important enough that they practice the hell out of it in simulators. If I could only remember where I read that, I'd give you a link.

Of course, I wouldn't know, I don't have 46 years driving 747s...I only know of MSFS. However, I know that your knowledge is higher given your frequent airliner rides.

[Gabriel]

TOPMS is gonna be monitoring and might just spit out a false warning if a swarm of dragonflies smacks the pitot tubes.

Now we are discussing constructively.
- Should be abort if we are badly UAS before V1? How would the flight director react after that? This is a phase of flight where airspeed is super-critical (especially if you don't have an AoA indicator).
- If not, we can consider using the inertial acceleration instead of the airspeed trend. Dragonflys don't affect that (unless in instead of a swarm you encounter a mountain of them).
- Note that my simpler proposal is not a full blown TOMPS, but just an indication that is available continuously and specifically checked at least once (at 80 knots). The trend would either go crazy or disappear, but the pilot can choose not to abort.
- Even with a full blown TOMPS the pilot can choose to cancel the aural warning and continue with the take off.
- We can also inhibit the full blown TOMPS above a given speed (say 100 knots).
- Or, as Evan said, take the risk to end up in the grass with some flat tiers and very hot brakes, if the judgement is that this is the least risky alternative.

But at this point it is very clear to me that NOT having a way to tell if the acceleration is good or not is NOT the safest alternative. Big planes have already crashed and people have already died. And these very serious incidents keep happening at a rate of a handful per year. We also have had several close calls. Some of them saved more by the fate and luck than for any good design or pilot response.

[Gabriel]

Of course, I wouldn't know, I don't have 46 years driving 747s...I only know of MSFS. However, I know that your knowledge is higher given your frequent airliner rides.

Somehow I feel that this was not aimed at Evan...

[3WE]

...Now we are discussing constructively...

If so, I think 'we' have to admit that Bobbie's 20sec to 80 knots is not half bad... seriously.

It samples a big chunk before V1, yet gives warning kind of early for a generally calm abort.

Yeah, sure, I can envision shortcomings (evan though Even can't envision identical situations with his TOPMS).

I do think Bobby is dismissive that this is truly simple enough to be done with a smart phone, even though it would truly be done with mega scientific engineering on a 'real' system already on the plane. My video link a page or two back where Betty calls out taxi navigation is a contrast... yeah, taxi location is important, but getting up to speed seems a little more critical, so HAL looking over his shoulder SEEMS like it wouldn't hurt.

Now, there's another pilot around who also views all this as big time ass-hat parlor talk... I've found him to be pretty damn accurate, and am considering that as we suggest these important safety recommendations to the industry.

[Gabriel]

If so, I think 'we' have to admit that Bobbie's 20sec to 80 knots is not half bad... seriously.

Yes, that may work, but there are 2 issues with that:

1- It should be "X sec to 80 knots", and X be calculated for each take-off. The 20 seconds rule of thumb is too inaccurate.
2- It should be "X seconds from (say) 40 knots to 80 knots. The first knots are too variable since they depend on whether you start from stop or you make a rolling take-off, how fast you advance the thrust levers, if you make a stop (and how long) somewhere in the middle to stabilize both engines... Everything before the engines are stabilized at take-off thrust doesn't count, and the engines won't be stabilized at take-off thrust at the same airspeed or elapsed time in every take-off. And the problem is that the airspeed indicator doesn't show anything at very low speeds.

What is the speed at which the ASI becomes alive in a jet liner?

Also, you need to start a stopwatch at a very precise point, and stop a stopwatch at a very precise point, and do it exactly at 80 kts (a time where you need to look at the ASI), and watch the stopwatch.

In my method you only look at the ASI that you need to look at 80 knots anyway, and it doesn't matter if you look 2 seconds or knots before or after 80 knots because the acceleration is pretty constant along the take off roll (so 2 seconds or knots sooner or later will be about the same), unlike the speed or the time both of which increase a lot and quickly along the take-off.