Go Back  PPRuNe Forums > Flight Deck Forums > Tech Log
Reload this Page >

Takeoff performance monitoring.

Tech Log The very best in practical technical discussion on the web

Takeoff performance monitoring.

Old 8th Dec 2011, 20:59
  #1 (permalink)  
Thread Starter
 
Join Date: Jul 2003
Location: An Island Province
Posts: 1,254
Likes: 0
Received 1 Like on 1 Post
Takeoff performance monitoring.

The UK AAIB’s report into an erroneous weight-input related takeoff incident recommends the development and requirement for a takeoff performance monitoring system. See Air Accidents Investigation: Airbus A321-211, G-NIKO

I wonder if such recommendations are somewhat premature before considering possible side effects of such a change, and also as it appears that the contributors to the cause of this event and similar (human related), have not been fully defined or perhaps understood – Australian/French reports.

A takeoff performance monitoring system would require a high level of reliability to avoid unwarranted alerts. Furthermore, presuming that a detection method would compare acceleration / rates, and position, the computational effort could be high and time period required for accurate output, relatively lengthy.
Thus, if an alert was given, it would likely occur in the high speed segment of a takeoff, and possibly further down the runway than would have been expected for a take with a correctly computed weight/speed/thrust level. This could increase the risk of an overrun if the takeoff was rejected – a logical action, as the exact reason for the poor acceleration would not be known.
Therefore use of a takeoff performance monitoring system might introduce additional risk in operations, particularly where aspects of erroneous data entry already have some safe guards, e.g. certification requirements for Vmu, minimum lift off speeds, tailstrike / geometry limits, rotation pitch limit.

Also note Air Accidents Investigation: Gulfstream G150, D-CKDM a brake related takeoff incident, as might have been the recent Yak 42 accident.
alf5071h is offline  
Old 8th Dec 2011, 21:54
  #2 (permalink)  
 
Join Date: Jan 2001
Location: Dallas, TX USA
Posts: 739
Likes: 0
Received 0 Likes on 0 Posts
Here's another one, the 747 Halifax accident from 2004.

ASN Aircraft accident Boeing 747-244B (SF) 9G-MKJ Halifax International Airport, NS (YHZ)

After the Halifax accident, takeoff performance monitoring was extensively discuss in that accident thread. However I don't recall that an adequate solution was found.

As I think about it now, an appropriately sensitive horizontal accelerometer tied into the FMC should work. All the FMC has to do is calculate an expected acceleration range for the entered weight and conditions and compare it to the measured acceleration, after the throttles move forward and the aircraft starts rolling. Modern airliners already have a vertical accelerometer, so why not add a horizontal one and add the software and crew alert logic to the FMC. This software use should be limited to the WOW condition only.

Come to think of it, the IMUs should be able to provide the acceleration data.

Last edited by Flight Safety; 9th Dec 2011 at 08:55.
Flight Safety is offline  
Old 9th Dec 2011, 08:30
  #3 (permalink)  
 
Join Date: Sep 1998
Location: wherever
Age: 54
Posts: 1,616
Likes: 0
Received 0 Likes on 0 Posts
Discipline and a gross error check.

Costs nothing, solves the problem.
FE Hoppy is offline  
Old 9th Dec 2011, 08:43
  #4 (permalink)  
 
Join Date: Apr 2008
Location: A tropical island.
Posts: 460
Likes: 0
Received 0 Likes on 0 Posts
Common sense is not a common virtue.

Reminds me of the old 2/3 and a 1/2 rule... If half the runway's gone by and you're not at more than 2/3 of your takeoff speed, something is off. Good rule of thumb, especially if you fly a plane and work at a company where you don't get your hand slapped for making a power adjustment on the roll.

Over-reliance on technological solutions (ie. accelerometers to determine the power is set correctly) only serves to reduce the overall quality of airman-ship. Just as I've seen many pilots go from looking for traffic with the Mark 1 Eyeball Radar to relying solely on TCAS to avoid traffic.
aviatorhi is offline  
Old 9th Dec 2011, 08:59
  #5 (permalink)  
 
Join Date: May 2001
Location: A few degrees South
Posts: 809
Likes: 0
Received 0 Likes on 0 Posts
At the end of the day, flying an airplane is still a profession.
Building in gimmicks is still not idiot proof.
latetonite is offline  
Old 9th Dec 2011, 17:47
  #6 (permalink)  
Thread Starter
 
Join Date: Jul 2003
Location: An Island Province
Posts: 1,254
Likes: 0
Received 1 Like on 1 Post
Suggesting a technical solution is a reaction to an outcome; the solution might not address the contributing factors thus further problems may arise.
A takeoff performance monitor based on acceleration could (with additional risk) detect a low thrust setting, but it is unlikely to detect an incorrect speed setting for weight and/or configuration.

It would be sensible to review what has changed; has the frequency (rate) of this type of incident actually increased? If so then what changes have there been which might contribute to the issue.
The obvious candidate is technology, but this also involves human interaction. Technology should be able to provide a very high level of error detection / prevention; apparently a sufficient level was achieved with previous methods, e.g weight and speed cards. Did previous methods have intrinsic defenses or generate specific crew skills, e.g. never showing ZFW on the card (irrelevant), or routine card use provided a mental pattern of the normal range of speed / weight / thrust combinations – a rule of thumb check.

Similarly, suggestions for ‘airmanship’ qualities are of little value unless the specific qualities are defined and the mechanism of defense explained. From these it might then be possible to train and improve these features. Unfortunately, even with excellent human qualities everyone can suffer inadequate performance due internal or external influences, and currently we can neither identify nor control these.

Perhaps a greater concern is that outside influences are affecting the human interaction with technology, e.g. shorter turnaround times increase the pressure to rush tasks.
Have turnaround times have been reduced because tasks have been automated, but then these tasks suffer from the tendency to rush, etc, etc. What other factors may contribute to current problems, what else has changed – human, technology, environment, society?

The industry strives to improve safety; this will probably have to involve both the human and technology. However, the use of technology should not trigger additional pressures on human behavior; any freed-up time could be used to ‘create safety’. Alternatively we could consider using a mixture of the old and new; instead of crosschecking the output of two computers (garbage in/garbage out), use speed cards as a cross check – and you might need these if the computers are on the MEL.
alf5071h is offline  
Old 10th Dec 2011, 00:10
  #7 (permalink)  
 
Join Date: Feb 2008
Location: Stockport
Age: 84
Posts: 282
Likes: 0
Received 0 Likes on 0 Posts
Takeoff performance monitoring has been discussed here several times over the past two or three years, and probably in connection with every over-weight takeoff incident for even longer.

Various high-tech and low-tech solutions are put forward, arguments against them rolled out, and everything goes quite again.

The simplest approach I have seen is to compute the expected time to V1, or ideally some lower speed, something that should drop out easily from the routine takeoff calculations, and then abort the takeoff if the reference speed is not reached in the calculated time.
Dairyground is offline  
Old 10th Dec 2011, 01:09
  #8 (permalink)  
 
Join Date: Dec 2002
Location: UK
Posts: 2,451
Likes: 0
Received 8 Likes on 4 Posts
Dairyground,
Simple solutions may have merit, but they have to demonstrate practicality and reliability; if not they may make the situation worse.

What margin of time should be considered to allow for variations in wind-speed, change in crosswind, variations in runway condition, runway texture, tyre effects. What margin is there in setting and reading the clock?
Say an accumulative 2 sec. Even in my old puffer jet with a 20 sec ground roll – to V1 or more, 2 sec is 10%; can we afford that 10% of take-offs might fall into a possible RTO category, with associated hazards?

Timing is fixing an outcome, this is reactive safety; the industry has to understand the cause so that proactive safety measures can be found – avoid, prevent, not mitigate in critical flight phases.
safetypee is offline  
Old 10th Dec 2011, 01:19
  #9 (permalink)  
 
Join Date: Jun 2010
Location: Brisbane, Australia
Posts: 304
Likes: 0
Received 0 Likes on 0 Posts
Well, I spent the first 10 years flying heavy metal in the military.
I was taught to calculate the 80 knot and VR speeds as distance covered, since all the military airfields had distance markers adjacent to the runway.
I always felt that was a simple and very effective way to check takeoff performance, and surprised when I changed to civil flying, that there was both no distance markers, and no method provided to calculate it anyway!

After 25 years and 14K hours, I still miss that reassuring check during takeoff.

Cheers....EW73
EW73 is offline  
Old 10th Dec 2011, 03:41
  #10 (permalink)  
 
Join Date: Feb 1998
Location: Formerly of Nam
Posts: 1,595
Likes: 0
Received 0 Likes on 0 Posts
I recall the Lockheed Electra L188 came fitted with a weight
and CG calculator based on the actual weight acting on all 3
mains. Whether this was an airline mod or Lockheed standard
I don't know, but according to Wombats I knew (AN L188) it
picked up those rare gross loading errors that could've led to
some performance grief.

Unlike the A320 suck-squirt that only calculates GWFK in the
air (and subject to AOA error) this thing gave the direct CG &
weight before even the engines were started, AND was simple
to use.
Slasher is offline  
Old 11th Dec 2011, 19:19
  #11 (permalink)  
Moderator
 
Join Date: Apr 2001
Location: various places .....
Posts: 7,177
Received 92 Likes on 61 Posts
I recall the Lockheed Electra L188

A useful widget - the detailed system memory is a tad faded now but the basics were that we checked the numbers on taxi. Weight was reasonably accurate and each aircraft had a reasonably constant CG error which could be allowed for.

More than a few occasions where the system picked up loading errors - generally these were the result either of weighbridge defects existing as the cans were rolled across or cans which were not entirely on the weighbridge and part supported on the edge frame. I vaguely recall one problem we picked up where there was a bit of FOD in the weighbridge causing a repeatable error in the weigh figures.

The F/O, religiously, checked off the can tags against the loadsheet summary page .. very occasionally, can loading order errors were detected.

To give credit where credit was due, the freightshed guys and gals were pretty good and made very few errors. Flightcrew checks and balances were a good foil to shed errors and the operation, overall, went very well.

Far better to delay the flight and fix whatever at the shed rather than finding out about the problem during rotation ..

The most exciting example of this (and I can't recall whether it was on the Goose or one of the 727 freighters, although I think the former) .. a pond of water, on rotation, found its way into the hell hole and all went dark .. in the middle of the night. Apparently caused the crew a few concerns during the following 10-15 minutes or so while they sorted it out and got the aircraft back onto the ground.

Wonderful times ..
john_tullamarine is offline  
Old 11th Dec 2011, 21:02
  #12 (permalink)  
Per Ardua ad Astraeus
 
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes on 0 Posts
It certainly seems that a TOCW which detects more than xxxpsi in the brake circuit might be a good idea? Simple and cheap - did I say foolproof..........?
BOAC is offline  
Old 12th Dec 2011, 01:56
  #13 (permalink)  
 
Join Date: Feb 1998
Location: Formerly of Nam
Posts: 1,595
Likes: 0
Received 0 Likes on 0 Posts
and all went dark .. in the middle of the night.
PP mentioned that John - an Electra rotated and the electrics
fizzed out when water, pooled in the front floor area close to
the cockpit (the Goose had a nose-down attitude while on the
ground?), sloshed aft and found its way into the AC bus area
and all the lights went out. If I recall him correctly (before we
descended into alcoholic oblivion) this problem was solved by
thickly speed-taping the entire floor.

Amazing what you find out about other people's aeroplanes
over a beer.
Slasher is offline  
Old 12th Dec 2011, 02:44
  #14 (permalink)  
Moderator
 
Join Date: Apr 2001
Location: various places .....
Posts: 7,177
Received 92 Likes on 61 Posts
Much effort went into sealing the floor on both Goose and 727.

One of the concerns was that we often took horse charters hither and thither. I well recall gently placing the aircraft on the ground in Sydney following a sector from NZ ... gracefully easing the levers into reverse ... and listening to the sound of the surf from the main cabin.

... mind you, my bags were on top of the pile so all was well with the world ..
john_tullamarine is offline  
Old 12th Dec 2011, 02:58
  #15 (permalink)  
 
Join Date: Apr 2004
Location: Planet Earth
Posts: 2,083
Likes: 0
Received 8 Likes on 7 Posts
Similar investigation:
"Continental 795" / 2Mar94 MD82 T/O Abort Over-run at LGA Rwy 13, aircraft jumped the "burm" or dike at the southeast rwy end ; resting on the dike. Actual speed may have been faster Indicated Airspeed. Planned V1=138, Vr=143; F/O's T/O, but Capt did the RTO. Capt Phillip Wright told NTSB his IAS rose to 60 KIAS, spiked to 80 KIAS, dropped to 60 KIAS. F/O stated IAS hovered at 60 KIAS. Winds = 070/19G25 to 35 kts. FDR: shows F/O's IAS less than crew reported (suggests faulty IAS?); FDR Longitudinal Acceleration contradicted low IAS; pilots' Airspeed Indicators should have shown 60 KIAS after 14 seconds and 600' of starting T/O roll; but even after an interval of 34 s & 3600' of roll their's showed no steady increase in airspeed. [RTO'd, Rwy excursion off-end, finally stopped cantilevered on dike.] \\ FDR engine data showed normal thrust. \\ _AWST_ 21Mar94 showed photo of fuselage buckling-ripple, running vertically at the 11th window forward of wing LE (between the two forward cargo doors).




Pitot icing was the (unrecognized) problem in this accident.


Incidentally, this Aircraft was totally rebuilt in a hangar at the La Guardia airport which we nicknamed 'Long Beach East' and was the nicest flying MD80 I ever flew after that (i realise that's not saying much)
stilton is offline  
Old 12th Dec 2011, 16:41
  #16 (permalink)  
 
Join Date: Feb 1998
Location: Formerly of Nam
Posts: 1,595
Likes: 0
Received 0 Likes on 0 Posts
Much effort went into sealing the floor on both Goose and 727.
TAA's 9s weren't pure freighters so we didn't get any problem
with rain getting in or any pools of horse piss sloshing around
John.

BTW mate I never could decide if 2 blow jobs were better than
4 screws!




Sorry for the slight thread drift everybody.
Slasher is offline  
Old 12th Dec 2011, 22:43
  #17 (permalink)  
Moderator
 
Join Date: Apr 2001
Location: various places .....
Posts: 7,177
Received 92 Likes on 61 Posts
One of my few regrets was not taking an assignment on the DC9. Five years in the Wombat Squadron was good fun, though. Good to see the pix with the little fellow adorning the nose ...
john_tullamarine is offline  

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service

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