EK407 Tailstrike @ ML
Join Date: Aug 2008
Location: Austin
Posts: 8
Likes: 0
Received 0 Likes
on
0 Posts
GearDown&Locked
I don't know for sure but I suspect both the speed relationship with time and with distance are non-linear.
I'm a great believer in K.I.S.S. and in this case you don't need complex integrals of ground speed to get distance - if you (or your computer) can calculate the expected time to V1 & VR for the weight and power settings, then you check your speed at those times - if your speed is below the projections you're running into trouble, but at least you know you have the tarmac left to stop. If the speed is at or above projections at those times then you're good to go.
This approach is inherently safer than measuring time to V1 - what happens in that case if acceleration is low? You could easily find yourself in a position where you don't have space to stop.
I don't know for sure but I suspect both the speed relationship with time and with distance are non-linear.
I'm a great believer in K.I.S.S. and in this case you don't need complex integrals of ground speed to get distance - if you (or your computer) can calculate the expected time to V1 & VR for the weight and power settings, then you check your speed at those times - if your speed is below the projections you're running into trouble, but at least you know you have the tarmac left to stop. If the speed is at or above projections at those times then you're good to go.
This approach is inherently safer than measuring time to V1 - what happens in that case if acceleration is low? You could easily find yourself in a position where you don't have space to stop.
it's paper pusher's heaven: Basically you must document your 'process', and show compliance to that process. The process it's self can be as broken as you like, just so long as you have a (documented) process (and follow it)
In the real world, customers will tell you everytime when you're providing a rubbishy service or product, either with or without ISO 9000 certification.
Join Date: Jan 2008
Location: North America
Posts: 58
Likes: 0
Received 0 Likes
on
0 Posts
Revman2 is right, it's a question of corporate commitment to quality, and whether its just pushed down from the top.
Turns out there is a specific application of ISO 9000 type standards for aerospace that "recognizes the role of regulatory authorities":
Society of Automotive Engineers (SAE)
AS9100: Quality Systems
Aerospace - Model for Quality Assurance in Design,
Development, Production, Installation, and Servicing
NIST GSIG: SAE AS9100: Quality Systems/Aerospace
All this is no panacea though, it's still up to the people involved, and more importantly (as reflected in this thread) the corporate culture -- whether ISO certified or not.
Turns out there is a specific application of ISO 9000 type standards for aerospace that "recognizes the role of regulatory authorities":
Society of Automotive Engineers (SAE)
AS9100: Quality Systems
Aerospace - Model for Quality Assurance in Design,
Development, Production, Installation, and Servicing
NIST GSIG: SAE AS9100: Quality Systems/Aerospace
All this is no panacea though, it's still up to the people involved, and more importantly (as reflected in this thread) the corporate culture -- whether ISO certified or not.
Join Date: Mar 2007
Location: Roguesville, cloud cuckooland
Posts: 1,197
Likes: 0
Received 16 Likes
on
5 Posts
I agree with Bernardd 173. Waiting till V1 to get an acceleration check would be too long and the V1 calculation and would be invalidated by the initial error anyway.
A time check to 80 knots would be much more useful, and guarantee that any subsequent rejected take-off would be in the low speed regime and with sufficient runway to stop.
A time check to 80 knots would be much more useful, and guarantee that any subsequent rejected take-off would be in the low speed regime and with sufficient runway to stop.
Join Date: Aug 2007
Location: London, New York, Paris, Moscow.
Posts: 3,632
Likes: 0
Received 0 Likes
on
0 Posts
ISO 9000?
Once put to me as "It ensures you can produce anything including a total load of crap as long as you can consistantly make the same total load of crap every day".
It doesn't mean your product is any good, just consistant!
Once put to me as "It ensures you can produce anything including a total load of crap as long as you can consistantly make the same total load of crap every day".
It doesn't mean your product is any good, just consistant!
so obviously your customer is consistently wide of the mark as they pay you $$$$$$$$$$ bucks for your consistently poor product that complies with their consistently poor performance markers...idiot!
Join Date: Nov 2005
Location: US
Posts: 63
Likes: 0
Received 0 Likes
on
0 Posts
All this discussion about times to V1 and assessing whether the take off is proceeding normally is all very interesting. BUT, the problem is that it’s very subjective.
Risk management design just doesn’t allow this type of guesswork into such critical phases of flight.
We need to come back to the take off data as designed by the manufacturer and certified by state authorities as the reference performance document .
Data is accessed on every take off, whether it’s via tables or laptop and, (unfortunately) relies on human input to obtain correct figures. If the crew, on the day, make an error in the input data, then they’ve made an error and wear the consequences (aircraft loss, damage, injury etc) as seen in numerous incidents and accidents with varying outcomes.
This error though, is the end result only. In most take off events such as this, there are generally systemic issues that prevented error trapping at multiple points during the pre flight, start, taxy stages of the flight, before the aircraft has even lined up on the runway.
We have to accept that it’s “normal” for all of us to make errors. That’s why we design processes that supposedly mitigate against the types of errors we are talking about.
Design of error management and trapping processes and procedures is the responsibility of management, not the responsibility of line pilots. Crews should follow these SOP’S with the reasonable expectation that they contain appropriate traps to prevent that final error.
If crews choose deliberately ignore SOP’s, then, yes, they have to accept responsibility.
But, if the process itself is flawed, then it’s senior management who must accept most of this responsibility.
Sadly, history has proved that flight crews are often the scapegoats for senior management shortcomings. This event will probably be no different.
Risk management design just doesn’t allow this type of guesswork into such critical phases of flight.
We need to come back to the take off data as designed by the manufacturer and certified by state authorities as the reference performance document .
Data is accessed on every take off, whether it’s via tables or laptop and, (unfortunately) relies on human input to obtain correct figures. If the crew, on the day, make an error in the input data, then they’ve made an error and wear the consequences (aircraft loss, damage, injury etc) as seen in numerous incidents and accidents with varying outcomes.
This error though, is the end result only. In most take off events such as this, there are generally systemic issues that prevented error trapping at multiple points during the pre flight, start, taxy stages of the flight, before the aircraft has even lined up on the runway.
We have to accept that it’s “normal” for all of us to make errors. That’s why we design processes that supposedly mitigate against the types of errors we are talking about.
Design of error management and trapping processes and procedures is the responsibility of management, not the responsibility of line pilots. Crews should follow these SOP’S with the reasonable expectation that they contain appropriate traps to prevent that final error.
If crews choose deliberately ignore SOP’s, then, yes, they have to accept responsibility.
But, if the process itself is flawed, then it’s senior management who must accept most of this responsibility.
Sadly, history has proved that flight crews are often the scapegoats for senior management shortcomings. This event will probably be no different.
Join Date: Oct 2008
Location: Under the Long Grey Cloud
Age: 76
Posts: 97
Likes: 0
Received 0 Likes
on
0 Posts
Unfortunately this thread is littered with "Stable Door" solutions for dealing with gross errors. (Most are assuming some sort of gross error in the takeoff weight calculation and/or thrust setting).
Threat and Error Management (TEM) should have trapped any errors long before the aircraft started the takeoff run.
Timing and/or distance acceleration checks are just too late as any errors so discovered invalidate both the "Go" and "Stop" calculations (and probably use the erroneous information anyway !)
mrs nomer
you just beat me to the same conclusion as I was composing this offline
Threat and Error Management (TEM) should have trapped any errors long before the aircraft started the takeoff run.
Timing and/or distance acceleration checks are just too late as any errors so discovered invalidate both the "Go" and "Stop" calculations (and probably use the erroneous information anyway !)
mrs nomer
you just beat me to the same conclusion as I was composing this offline
Join Date: Jan 2008
Location: Jerudong/
Posts: 52
Likes: 0
Received 0 Likes
on
0 Posts
Has anyone built and tested one of these yet? http://www.patentstorm.us/patents/6133857/description.html Not that I have seen, but then I am not a pilot, simmer or aircraft engineer. I guess that many would say that such a device is an unnecessary expense for what amounts to a double-check. Others might see it as an essential piece of safety equipment.
The key element in this design appears to be the independently derived real-time data, which does not rely 'assumed' values entered before t/o, but calculates them during the roll. As long as the right airport and runway is entered into the FMGC, it should 'work'. For complete confidence, link the system to the auto thrust.
The key element in this design appears to be the independently derived real-time data, which does not rely 'assumed' values entered before t/o, but calculates them during the roll. As long as the right airport and runway is entered into the FMGC, it should 'work'. For complete confidence, link the system to the auto thrust.
NOT Guesswork
Risk management design just doesn’t allow this type of guesswork into such critical phases of flight.
Although the preliminary report will probably clarify this, it seems clear to most of us here that they weren't accelerating fast enough and should have recognized it. Although management should give them the tools to recognize insufficient acceleration, and maybe did, it seems like the crew was asleep until the end of the runway loomed in the windscreen.
Join Date: Apr 2005
Location: Building Site
Posts: 293
Likes: 0
Received 0 Likes
on
0 Posts
Acceleration check is NOT the solution
Gentlemen, again...
I have to agree with mrs nomer and ZimmerFly. This should have been trapped before the aircraft starts rolling. I think the SOP's we use at EK are wellequiped for that, but unfortunately, lapses do happen, especially operating in an environment such as EK for reasons well explained before and in other threads.
GearDown&Locked:
Your check would indeed work if you knew the correct v1/vr/v2. If the error has been one of entering the wrong weight, your speeds will be a lot lower then required, and even with your acceleration check being ok, you will run out of runway before getting airborne. And this time with a safe feeling because your acceleration check has been ok...
Just for your info, on the typical EK A345 operations, we do very short trips on the A345 as well as the ultra long haul it was designed for, Hence, our v2 speeds will range from somewhere in the lower 130's up to the higher 170's.
Again, about the whole acceleration check thing. As I posted before I am completely AGAINST it. It is NO good way of checking your take off numbers. If you do your checklater in the takeoff roll, it is too dangerous to stop. You might have encountered more tailwind then expected, a windshear, ... Since you don't know if you can still stop, it is ALWAYS better to hit the TOGA and GO!!
I know that you could calculate the correct GS vs. Runway remaining etc.. but then you would get kind of conditional speeds. Like in: Before the v1 of xxx knots we call STOP unless the GS is XXX and the runway remaining etc etc... Not a good situation for a speed designed to make a QUICK STOP/GO decision.
Whilst an acceleration check at 80 knots vs. remaining runway might sound like a safer option, since you will always have enough runway to stop if the check should be unsatisfactory: even this check would be useless. At lower speeds such a check can only be done out of a static TO condition, e.g. beginning of the runway, stopped, applying thrust. Loads of time we enter the runway for a rolling take off. If this is done in an expeditious way, we are above 30 knots by the time we apply TO thrust. An acceleration check at lower speeds would thus be invalid and set you up with a false sense of safety.
Conclusion: the ONLY way to stop this kind of errors is to either have the ACTUAL aircraft weight at your disposal for a crosscheck (which the industry wouldn't like) or as mentioned in the start of my post, by trapping the error before the doors are shut.
MR8
I have to agree with mrs nomer and ZimmerFly. This should have been trapped before the aircraft starts rolling. I think the SOP's we use at EK are wellequiped for that, but unfortunately, lapses do happen, especially operating in an environment such as EK for reasons well explained before and in other threads.
GearDown&Locked:
Your check would indeed work if you knew the correct v1/vr/v2. If the error has been one of entering the wrong weight, your speeds will be a lot lower then required, and even with your acceleration check being ok, you will run out of runway before getting airborne. And this time with a safe feeling because your acceleration check has been ok...
Just for your info, on the typical EK A345 operations, we do very short trips on the A345 as well as the ultra long haul it was designed for, Hence, our v2 speeds will range from somewhere in the lower 130's up to the higher 170's.
Again, about the whole acceleration check thing. As I posted before I am completely AGAINST it. It is NO good way of checking your take off numbers. If you do your checklater in the takeoff roll, it is too dangerous to stop. You might have encountered more tailwind then expected, a windshear, ... Since you don't know if you can still stop, it is ALWAYS better to hit the TOGA and GO!!
I know that you could calculate the correct GS vs. Runway remaining etc.. but then you would get kind of conditional speeds. Like in: Before the v1 of xxx knots we call STOP unless the GS is XXX and the runway remaining etc etc... Not a good situation for a speed designed to make a QUICK STOP/GO decision.
Whilst an acceleration check at 80 knots vs. remaining runway might sound like a safer option, since you will always have enough runway to stop if the check should be unsatisfactory: even this check would be useless. At lower speeds such a check can only be done out of a static TO condition, e.g. beginning of the runway, stopped, applying thrust. Loads of time we enter the runway for a rolling take off. If this is done in an expeditious way, we are above 30 knots by the time we apply TO thrust. An acceleration check at lower speeds would thus be invalid and set you up with a false sense of safety.
Conclusion: the ONLY way to stop this kind of errors is to either have the ACTUAL aircraft weight at your disposal for a crosscheck (which the industry wouldn't like) or as mentioned in the start of my post, by trapping the error before the doors are shut.
MR8
Join Date: Aug 2007
Location: DUBAI
Posts: 11
Likes: 0
Received 0 Likes
on
0 Posts
The latest from MEL is that the evaluation work on the repair has just finished. Rear pressure bulkhead is cracked . Aircraft has been moved into the Old Ansett hangar at a cost of $28,000 per night ! Rumour that an Insurance write off is now being considered as cost of repair and requirement to get the a/c to Toulouse (unpressurised at 10,000ft ) to carry out the repair work is going to cost a fortune. At least 3 months out of service for repair work to be completed.
This should have been trapped before the aircraft starts rolling.
Join Date: Feb 2000
Location: asia
Posts: 542
Likes: 0
Received 0 Likes
on
0 Posts
And that is the problem.
If you want to build a system to catch errors in another system, then you have to assume that everything in the system being checked could possibly be screwed up.
If there is a possiblity that the weight can be input incorrectly into the first system, then you have to allow that the same error can be made if the weight is input into the second check system.
There again, if the weight could be derived automatically from sensors or weighbridge, why would we need the second check system anyway?
If you want to build a system to catch errors in another system, then you have to assume that everything in the system being checked could possibly be screwed up.
If there is a possiblity that the weight can be input incorrectly into the first system, then you have to allow that the same error can be made if the weight is input into the second check system.
There again, if the weight could be derived automatically from sensors or weighbridge, why would we need the second check system anyway?
Join Date: Jan 2004
Location: LPPT
Age: 58
Posts: 431
Likes: 0
Received 0 Likes
on
0 Posts
The main idea is to give you some predictive notion of how fast you're going to reach your calculated V1, for instance.
IMHO this aid could be as simple as coloring the speed trend arrow from red to yellow to green while on the TO roll, depending on the acceleration the A/C versus the distance it travels on the ground. This is not a system that checks another system, simply a visual cue for the numbers the pilot has punched in.
If you keep getting a red arrow along the TO roll until, let's say 80 or 100 KIAS, it means that you're not getting enough acceleration to get airborne inside the RWY distance. V1 doesn't come into play here as you could be too slow for TO but well inside a perfectly safe braking distance.
GD&L
IMHO this aid could be as simple as coloring the speed trend arrow from red to yellow to green while on the TO roll, depending on the acceleration the A/C versus the distance it travels on the ground. This is not a system that checks another system, simply a visual cue for the numbers the pilot has punched in.
If you keep getting a red arrow along the TO roll until, let's say 80 or 100 KIAS, it means that you're not getting enough acceleration to get airborne inside the RWY distance. V1 doesn't come into play here as you could be too slow for TO but well inside a perfectly safe braking distance.
GD&L
For info the outfit that I am familiar with uses reduced thrust / flex takeoffs wherever possible and I think that most outfits do. In lay terms this uses an "assumed temperature" method of calculating thrust that "fools the aeroplane" into thinking that it is weight limited due to ambient temp.
Hence the aircraft always rotates at about the same distance from the end regardless of weight. (Sounds funny until you think about it / less weight - less thrust).
Following on from this the length of the trend vector is always roughly about the same - regardless of weight. In the particular aircraft I am familiar with it is about "25 - 30 kts in length". The only time it varies is on a light weight/high thrust takeoff - unusual but possible due to contamination or MEL requirements etc. In this case the thrust vector is longer. So a simple "gross error" check can be made very early in the takeoff roll - like just after thrust is fully set.
In my aircraft, if the length of the trend vector is less than 25 - 30 kts - stop! It can be done so early in the takeoff roll that the stop is quite gentle - i.e not a passenger screaming abort at high speed. As I'm sure most drivers are aware the trend vector is a fabulous indicator of wind shear on the runway and I am a big believer of the PM being "trend vector aware" during the takeoff roll.
Following the Auckland accident I tried setting up the FMC (in the Sim) with the ZFW set as the TOW and believe me the trend vector was really short - like about 5 - 10 kts. Unforunately the heavies in our airline didn't want to consider introducing the idea of trend vector monitoring by the PM as standard. They did concede however that it was acceptable as an "individual airmanship check".
Interested in whether other use this or considered views.
Hence the aircraft always rotates at about the same distance from the end regardless of weight. (Sounds funny until you think about it / less weight - less thrust).
Following on from this the length of the trend vector is always roughly about the same - regardless of weight. In the particular aircraft I am familiar with it is about "25 - 30 kts in length". The only time it varies is on a light weight/high thrust takeoff - unusual but possible due to contamination or MEL requirements etc. In this case the thrust vector is longer. So a simple "gross error" check can be made very early in the takeoff roll - like just after thrust is fully set.
In my aircraft, if the length of the trend vector is less than 25 - 30 kts - stop! It can be done so early in the takeoff roll that the stop is quite gentle - i.e not a passenger screaming abort at high speed. As I'm sure most drivers are aware the trend vector is a fabulous indicator of wind shear on the runway and I am a big believer of the PM being "trend vector aware" during the takeoff roll.
Following the Auckland accident I tried setting up the FMC (in the Sim) with the ZFW set as the TOW and believe me the trend vector was really short - like about 5 - 10 kts. Unforunately the heavies in our airline didn't want to consider introducing the idea of trend vector monitoring by the PM as standard. They did concede however that it was acceptable as an "individual airmanship check".
Interested in whether other use this or considered views.
Join Date: Jan 2008
Location: UK
Posts: 1,464
Likes: 0
Received 0 Likes
on
0 Posts
I guess the per-night charges at LBA back in '85 were relatively cheaper, as a TriStar spent some time there after a landing overrun. (watching it get put back on the runway and moved away was a local spectator sport for a couple of days)
Photos: Lockheed L-1011-385-1 TriStar 1 Aircraft Pictures | Airliners.net=
Photos: Lockheed L-1011-385-1 TriStar 1 Aircraft Pictures | Airliners.net=
Join Date: Mar 2006
Location: East of Eden
Posts: 101
Likes: 0
Received 0 Likes
on
0 Posts
Smilin Ed,
I can't agree with you at all.
In a very dynamic situation at speeds in the order of 160 KIAS, it's simply not possible to look outside and accurately determine whether planned acceleration is matched by actual. The aircraft at this stage is travelling at over 250 feet per second.,
Stick to the take off performance data. It's the most empirical data.
I can't agree with you at all.
In a very dynamic situation at speeds in the order of 160 KIAS, it's simply not possible to look outside and accurately determine whether planned acceleration is matched by actual. The aircraft at this stage is travelling at over 250 feet per second.,
Stick to the take off performance data. It's the most empirical data.