Balanced Field Length
Join Date: Jun 2004
Location: Australia
Posts: 1,843
Likes: 0
Received 0 Likes
on
0 Posts
Correct FE Hoppy, BFL does not consider obstacles. Operator's policy and techniques will vary, but for the Companies / Aircraft types that I'm responsible for as Performance Engineer, there are 2 approaches.
Primarily, I only use BFL for the production of 'General Takeoff Charts and Tables', this takes care of the 'Field Limits', i.e. Accelerate-Stop or Accelerate-Go to the screen height (nominally 35 feet). Now, from the end of the Runway, obstacles for the 1st and 2nd segment climbs are evaluated, and the 2 associated 1st / 2nd segment climb limits found. Now we have 3 limits, namely (1) The Field Limit, (2) the 1st segment limit, and (3) the 2nd segment limit. The MBRW is then the lesser of the 3 limits found. This may lead to some pretty horrendous limits, particularly when the 1st segment obstacles are 'close in'.
Alternatively, a technique is described in the Operations Manual/s for when the 1st/2nd climb limits are too restrictive. Steadily reduce the Field length in increments, thus making the distance to the obstacle greater, and the required gradient less. Thus, whilst the Field limit is reducing, the obstacle limit is increasing. Keep on reducing the Field length until the Field Limit and the Obstacle limit are as close as possible to each other, and Voila!, you've done a reasonable job of optimising the takeoff weight. The big 'sufferer' in all of this of course is the accelerate-stop limit (because you've been reducing the Field length), which need not have been so as the Accelerate-Stop is unaffected by obstacles.
The techniques described here are crude, but effective in achieving reasonable takeoff weights whenever the RTOW is invalidated. It's a brief and incomplete description, but it will keep you safe.
Take Care,
Old Smokey
Primarily, I only use BFL for the production of 'General Takeoff Charts and Tables', this takes care of the 'Field Limits', i.e. Accelerate-Stop or Accelerate-Go to the screen height (nominally 35 feet). Now, from the end of the Runway, obstacles for the 1st and 2nd segment climbs are evaluated, and the 2 associated 1st / 2nd segment climb limits found. Now we have 3 limits, namely (1) The Field Limit, (2) the 1st segment limit, and (3) the 2nd segment limit. The MBRW is then the lesser of the 3 limits found. This may lead to some pretty horrendous limits, particularly when the 1st segment obstacles are 'close in'.
Alternatively, a technique is described in the Operations Manual/s for when the 1st/2nd climb limits are too restrictive. Steadily reduce the Field length in increments, thus making the distance to the obstacle greater, and the required gradient less. Thus, whilst the Field limit is reducing, the obstacle limit is increasing. Keep on reducing the Field length until the Field Limit and the Obstacle limit are as close as possible to each other, and Voila!, you've done a reasonable job of optimising the takeoff weight. The big 'sufferer' in all of this of course is the accelerate-stop limit (because you've been reducing the Field length), which need not have been so as the Accelerate-Stop is unaffected by obstacles.
The techniques described here are crude, but effective in achieving reasonable takeoff weights whenever the RTOW is invalidated. It's a brief and incomplete description, but it will keep you safe.
Take Care,
Old Smokey
Join Date: Sep 2002
Location: La Belle Province
Posts: 2,179
Likes: 0
Received 0 Likes
on
0 Posts
Alternatively, a technique is described in the Operations Manual/s for when the 1st/2nd climb limits are too restrictive. Steadily reduce the Field length in increments, thus making the distance to the obstacle greater, and the required gradient less. Thus, whilst the Field limit is reducing, the obstacle limit is increasing. Keep on reducing the Field length until the Field Limit and the Obstacle limit are as close as possible to each other, and Voila!, you've done a reasonable job of optimising the takeoff weight. The big 'sufferer' in all of this of course is the accelerate-stop limit (because you've been reducing the Field length), which need not have been so as the Accelerate-Stop is unaffected by obstacles.
I'd be concerned that someone who *thinks* they know (but doesn't) will note you've used a shorter BFL than the available runway, and think "aha, I can takeoff from the intersection, rather than taxiing all the way to the end of the runway...."
Join Date: Jun 2004
Location: Australia
Posts: 1,843
Likes: 0
Received 0 Likes
on
0 Posts
Mad (Flt) Scientist,
To answer your second question first, the Operations Manuals that I've produced and alluded to PROHIBIT the use of intersection departures when General Charts / Tables are used.
To respond to your first question, "do all the crews realise exactly what you're doing", probably not. Whilst well written Operations Manuals are produced, and recurrent performance refresher courses etc. are carried out, there's still a significant number of pilots 'out there' who, having passed Performance 'A', promptly put it into the 'tick in the box' category and hope that they never need to use it. Methinks that the number of very basic performance related queries / responses on Pprune's pages are indicitave of this.
The best that we can do is produce the best possible performance material, training syllabi, and guidance to trainees, and hope that their professionalism is such that they would studiously apply it.
To answer your second question first, the Operations Manuals that I've produced and alluded to PROHIBIT the use of intersection departures when General Charts / Tables are used.
To respond to your first question, "do all the crews realise exactly what you're doing", probably not. Whilst well written Operations Manuals are produced, and recurrent performance refresher courses etc. are carried out, there's still a significant number of pilots 'out there' who, having passed Performance 'A', promptly put it into the 'tick in the box' category and hope that they never need to use it. Methinks that the number of very basic performance related queries / responses on Pprune's pages are indicitave of this.
The best that we can do is produce the best possible performance material, training syllabi, and guidance to trainees, and hope that their professionalism is such that they would studiously apply it.
Join Date: Jun 2004
Location: Australia
Posts: 1,843
Likes: 0
Received 0 Likes
on
0 Posts
FJJP.
To answer your question which I quote -
I respond with my own previous quote -
Old Smokey
To answer your question which I quote -
- is this subject not comprehensively covered as part of the ATPL study?
there's still a significant number of pilots 'out there' who, having passed Performance 'A', promptly put it into the 'tick in the box' category and hope that they never need to use it.
Join Date: Sep 1999
Location: ME
Posts: 5,505
Likes: 0
Received 0 Likes
on
0 Posts
Old_smokey,
If you were just talking about the basic BFL charts in an operations manual I would agree with you that they do not account for obstacles, as they are not airport/runway specific.
However the Boeing software methodology reduces the takeoff weight for the obstacle and then provides a balanced field solution. This data is then presented as a limiting takeoff weight and the speeds can be obtained directly from the FMS.
All companies don’t use this method; I have another electronic AFM that even though the input selection is "balanced", obstacles will “unbalance” the output.
It is therefore imperititive that crews KNOW exactly what their ops engineers are trying to do, this can only be achieved through adequate training and company procedures.
Mutt.
SR71,
Still interested in knowing how you actually brief the takeoff procedure. Using the lower V1 of 135kts, with the knowledge that you can safely abort at 165 kts. Do you brief your PNF that your maximum abort speed is 135 or 165?
Mutt.
If you were just talking about the basic BFL charts in an operations manual I would agree with you that they do not account for obstacles, as they are not airport/runway specific.
However the Boeing software methodology reduces the takeoff weight for the obstacle and then provides a balanced field solution. This data is then presented as a limiting takeoff weight and the speeds can be obtained directly from the FMS.
All companies don’t use this method; I have another electronic AFM that even though the input selection is "balanced", obstacles will “unbalance” the output.
It is therefore imperititive that crews KNOW exactly what their ops engineers are trying to do, this can only be achieved through adequate training and company procedures.
Mutt.
SR71,
Still interested in knowing how you actually brief the takeoff procedure. Using the lower V1 of 135kts, with the knowledge that you can safely abort at 165 kts. Do you brief your PNF that your maximum abort speed is 135 or 165?
Mutt.
Join Date: Mar 2000
Location: Arizona USA
Posts: 8,571
Likes: 0
Received 0 Likes
on
0 Posts
The most limiting sea level runway that I have personally operated from is FUK.
Takeoffs to the south (runway 16) are obsticle limited, whereas takeoffs to the north (runway 34) were field length limited...with TriStar -500 equipment.
Our routes were such that field length limited takeoffs were always performed on runway 34 (wind permiting of course) and therein was a problem.
The takeoff data was for a balanced field, yet I had no doubt whatsoever that trying to stop from anywhere near V1 would positively result in an overrun, something I personally was not about to tolerate.
So, I always had a short discussion with the other flight crew, and suggested that a reduction of V1 was appropriate, thereby avoiding an overrun (if required to stop) yet allowing the continued takeoff, with a lower screen height achieved, should an engine fail at the most unfortunate time.
Wet runway takeoff data (reduction of V1) was used, directly from the takeoff data supplied, and was derived from Air Canada manuals.
Seemed reasonable to me...and still does.
IMO, whatever it takes to keep you safe, and avoid that certainly unpleasant incident/accident.
Takeoffs to the south (runway 16) are obsticle limited, whereas takeoffs to the north (runway 34) were field length limited...with TriStar -500 equipment.
Our routes were such that field length limited takeoffs were always performed on runway 34 (wind permiting of course) and therein was a problem.
The takeoff data was for a balanced field, yet I had no doubt whatsoever that trying to stop from anywhere near V1 would positively result in an overrun, something I personally was not about to tolerate.
So, I always had a short discussion with the other flight crew, and suggested that a reduction of V1 was appropriate, thereby avoiding an overrun (if required to stop) yet allowing the continued takeoff, with a lower screen height achieved, should an engine fail at the most unfortunate time.
Wet runway takeoff data (reduction of V1) was used, directly from the takeoff data supplied, and was derived from Air Canada manuals.
Seemed reasonable to me...and still does.
IMO, whatever it takes to keep you safe, and avoid that certainly unpleasant incident/accident.
Join Date: May 1999
Location: Bristol, England
Age: 65
Posts: 1,804
Received 0 Likes
on
0 Posts
...but of course using the wet V1 left you about 10kt closer to a Vmcg that had been calculated without crosswind and might even have put you under your 'real' Vmcg on the day.
Which would have caused the utterance of a singularly appropriate expletive considering the ICAO code of the aerodrome in question.....
In HMFC's VC10s, we used either aerodrome-specific regulated take-off graphs, or 'general' balanced field graphs if RTOGs weren't available. For normal conditions a mid-range V1 was used; this varied for contaminated ops or for wet RWs.
Reduced thrust ('factored power') take-offs were OK using most general balanced field graphs; however, on some RWs it was necessary to use max chat - and to treat the locals to the 'silent and serene' sound of the mighty Vickers Whisperjet!
In HMFC's VC10s, we used either aerodrome-specific regulated take-off graphs, or 'general' balanced field graphs if RTOGs weren't available. For normal conditions a mid-range V1 was used; this varied for contaminated ops or for wet RWs.
Reduced thrust ('factored power') take-offs were OK using most general balanced field graphs; however, on some RWs it was necessary to use max chat - and to treat the locals to the 'silent and serene' sound of the mighty Vickers Whisperjet!
Join Date: Jun 2004
Location: Australia
Posts: 1,843
Likes: 0
Received 0 Likes
on
0 Posts
Mutt,
Agreed, on the one hand I was referring to basic Operations Manual BFL Charts where obstacles have to be considered separately.
On the other hand I was referring to those occasions when a published RTOW is invalidated (Usually by the appearance of a new obstacle), and in the interim period (often only a matter of hours) before the computer programme can generate temporary RTOWs, crews are required to use the "General Performance" data from the Operations manuals. This procedure is well spelled out to our crews, as I alluded to in a response to Mad (Flt) Scientist with the words "Whilst well written Operations Manuals are produced, and recurrent performance refresher courses etc. are carried out, there's still a significant number of pilots 'out there' who, having passed Performance 'A', promptly put it into the 'tick in the box' category and hope that they never need to use it. Every effort is made to convey to the pilot group the reasoning required to effect this, and it is gratifying that there is a growing awareness of performance appreciation and appropriate application in my company (This did not exist before, and I take some delight in having turned the tide).
The computer programmes that I've developed (from Manufacturer's AFM and Performance Manual data of course) rarely use the Balanced Field principal, as we regularly use Clearway and Stopway in MOST normal operations which, except in a few cases, are rarely equal. The major de-equalising (is that a word?) factor of course, is the presence of obstacles where the Optimised Continued Takeoff/Obstacle limit does not conflict with the separately computed Accelerate-Stop limit, the lesser of the 2 being the limit. This cannot be the case when forced to use "General Charts" when Balanced Field data is used in the instance of the RTOW being invalidated.
I mentioned elsewhere that I was primarily referring to the B777, but these same general principals, with their own idiosynchrasies, apply to the other aircraft that I do performance work for.
Sometimes I think we say the same things, but use different words.
Regards,
Old Smokey
Agreed, on the one hand I was referring to basic Operations Manual BFL Charts where obstacles have to be considered separately.
On the other hand I was referring to those occasions when a published RTOW is invalidated (Usually by the appearance of a new obstacle), and in the interim period (often only a matter of hours) before the computer programme can generate temporary RTOWs, crews are required to use the "General Performance" data from the Operations manuals. This procedure is well spelled out to our crews, as I alluded to in a response to Mad (Flt) Scientist with the words "Whilst well written Operations Manuals are produced, and recurrent performance refresher courses etc. are carried out, there's still a significant number of pilots 'out there' who, having passed Performance 'A', promptly put it into the 'tick in the box' category and hope that they never need to use it. Every effort is made to convey to the pilot group the reasoning required to effect this, and it is gratifying that there is a growing awareness of performance appreciation and appropriate application in my company (This did not exist before, and I take some delight in having turned the tide).
The computer programmes that I've developed (from Manufacturer's AFM and Performance Manual data of course) rarely use the Balanced Field principal, as we regularly use Clearway and Stopway in MOST normal operations which, except in a few cases, are rarely equal. The major de-equalising (is that a word?) factor of course, is the presence of obstacles where the Optimised Continued Takeoff/Obstacle limit does not conflict with the separately computed Accelerate-Stop limit, the lesser of the 2 being the limit. This cannot be the case when forced to use "General Charts" when Balanced Field data is used in the instance of the RTOW being invalidated.
I mentioned elsewhere that I was primarily referring to the B777, but these same general principals, with their own idiosynchrasies, apply to the other aircraft that I do performance work for.
Sometimes I think we say the same things, but use different words.
Regards,
Old Smokey
Moderator
Thread appears to get bogged down from time to time but is, nonetheless, a very important message to get across to the newchums periodically ..
Consider -
(a) the main aim is to come up with numbers to provide the operating crew with data unlikely to cause embarrassment - the bean counters may take a contrary view, of course
(b) the next aim is to be able to defend the numbers and processes in court
(c) the operating crew, however, must know enough about the basis of the numbers to operate in a manner compatible with the analysis.
(d) sometimes this results in pilots with not much more than a very elementary "do it this way" knowledge right through to folk who are competent to do the whole thing .. end user performance work is hardly rocket science .. one just needs to be methodical, disciplined, have good obstacle data and housekeeping.
(e) whether the analysis is balanced or unbalanced really is unimportant, provided that the numbers don't put the aircraft (on paper) off the side/end of the runway, into the hill, etc.
(f) balanced calcs are great for general charts to be used in association with climb gradient data by the pilot when the RTOW tables are invalid. Quick and dirty answer to the immediate problem without taking forever to do the sums ..
(g) except for folk who are used to using the AFM, it generally is not feasible for the line pilot to pull out the book on the ramp and do the full analysis. When one considers that the main problem is defining the actual obstacles, it would be pointless for the pilot to attempt an optimised calculation anyway.
(h) flight standards considerations are extremely important. While the bean counters have their part to play, often the difference between a balanced and unbalanced calculation is not significant so there may be the opportunity to use the simpler data to make it a bit easier on crew workload, etc. A similar argument can be made for facilitating the use of computer based cockpit assistance .. FMCs and the like.
(i) generally, unbalancing will provide extra payload so it is a good thing if the alternative is to leave a bunch of people behind at the terminal
(j) unbalancing to optimise the numbers may result in speed schedules which are not comfortable for the pilot .. considerations of high speed aborts become very relevant from the viewpoints of standardised practices and corporate risk control
.. and the list can be extended to further detail without too much effort ....
Consider -
(a) the main aim is to come up with numbers to provide the operating crew with data unlikely to cause embarrassment - the bean counters may take a contrary view, of course
(b) the next aim is to be able to defend the numbers and processes in court
(c) the operating crew, however, must know enough about the basis of the numbers to operate in a manner compatible with the analysis.
(d) sometimes this results in pilots with not much more than a very elementary "do it this way" knowledge right through to folk who are competent to do the whole thing .. end user performance work is hardly rocket science .. one just needs to be methodical, disciplined, have good obstacle data and housekeeping.
(e) whether the analysis is balanced or unbalanced really is unimportant, provided that the numbers don't put the aircraft (on paper) off the side/end of the runway, into the hill, etc.
(f) balanced calcs are great for general charts to be used in association with climb gradient data by the pilot when the RTOW tables are invalid. Quick and dirty answer to the immediate problem without taking forever to do the sums ..
(g) except for folk who are used to using the AFM, it generally is not feasible for the line pilot to pull out the book on the ramp and do the full analysis. When one considers that the main problem is defining the actual obstacles, it would be pointless for the pilot to attempt an optimised calculation anyway.
(h) flight standards considerations are extremely important. While the bean counters have their part to play, often the difference between a balanced and unbalanced calculation is not significant so there may be the opportunity to use the simpler data to make it a bit easier on crew workload, etc. A similar argument can be made for facilitating the use of computer based cockpit assistance .. FMCs and the like.
(i) generally, unbalancing will provide extra payload so it is a good thing if the alternative is to leave a bunch of people behind at the terminal
(j) unbalancing to optimise the numbers may result in speed schedules which are not comfortable for the pilot .. considerations of high speed aborts become very relevant from the viewpoints of standardised practices and corporate risk control
.. and the list can be extended to further detail without too much effort ....
Join Date: May 1999
Location: Bristol, England
Age: 65
Posts: 1,804
Received 0 Likes
on
0 Posts
Well....... its a neat summary but its an engineer's approach. The list is too long, you got down to (j) before you got bored, the pilots lost you at (c).
The problem isn't pilots who don't know what they're doing, they're likely to follow SOPs. The problem is not pilots who really know what they're doing, they will consider all the variables. The real problem, as always, is pilots who think they know what they are doing and don't, always the majority.
The answer can only be,
1. Operators, prepare the SOPs with the advice of specialists. Ask for what you want, the specialist will give it to you.
2. Pilots, always follow SOPs, do not deviate. You ain't paid to think.
Steps back and awaits incoming.
The problem isn't pilots who don't know what they're doing, they're likely to follow SOPs. The problem is not pilots who really know what they're doing, they will consider all the variables. The real problem, as always, is pilots who think they know what they are doing and don't, always the majority.
The answer can only be,
1. Operators, prepare the SOPs with the advice of specialists. Ask for what you want, the specialist will give it to you.
2. Pilots, always follow SOPs, do not deviate. You ain't paid to think.
Steps back and awaits incoming.
Mach 3
Join Date: Aug 1998
Location: Stratosphere
Posts: 622
Likes: 0
Received 0 Likes
on
0 Posts
Mutt
I've never questioned the standard SOP...until now!
Alex,
Hey, who are you calling a chimp?
Still interested in knowing how you actually brief the takeoff procedure. Using the lower V1 of 135kts, with the knowledge that you can safely abort at 165 kts. Do you brief your PNF that your maximum abort speed is 135 or 165?
Alex,
2. Pilots, always follow SOPs, do not deviate. You ain't paid to think.
Moderator
Alex,
.. actually, I'm an engineer who was perverted by being a pilot .. and a pilot who, likewise, suffered at the hands of boring engineers ... come to think of it, at times I'm not quite sure what I am. Mind you, many others have no hesitation in suggesting various answers to that question .. but that's entirely another matter ..
In fact, the poor guy who drew the short straw and got me to train as an intake airline FO didn't know what had hit him .. fortunately he had a good sense of humour and perservered so here I am still ...
But I concur with your thoughts ... 100 percent.
Well, maybe 99.9 percent.
A lot of sim training work suggests to me that the "legend in his own mind" is a menace and that the better breed of pilot is one who
(a) follows SOPs unless there is a very pressing and sensible reason to do otherwise
(b) doesn't do non-standard things without a good deal of thought and consideration, being well aware that a lot of armchair philosophy went into developing most SOPs.
(c) always considers the need to be able to explain his/her action(s) at a later time
.. actually, I'm an engineer who was perverted by being a pilot .. and a pilot who, likewise, suffered at the hands of boring engineers ... come to think of it, at times I'm not quite sure what I am. Mind you, many others have no hesitation in suggesting various answers to that question .. but that's entirely another matter ..
In fact, the poor guy who drew the short straw and got me to train as an intake airline FO didn't know what had hit him .. fortunately he had a good sense of humour and perservered so here I am still ...
But I concur with your thoughts ... 100 percent.
Well, maybe 99.9 percent.
A lot of sim training work suggests to me that the "legend in his own mind" is a menace and that the better breed of pilot is one who
(a) follows SOPs unless there is a very pressing and sensible reason to do otherwise
(b) doesn't do non-standard things without a good deal of thought and consideration, being well aware that a lot of armchair philosophy went into developing most SOPs.
(c) always considers the need to be able to explain his/her action(s) at a later time
