People,
Some interesting thoughts in the last few posts - some additional observations.
(a) Never using derate ?
This would be fine on a Type for which the engine installation is heavily derated to begin with (or if all your aerodromes were nasty ones) - otherwise, a very expensive way to operate (if there be no prohibition on derate, and that would be a little unusual). Perhaps there are operators out there for whom cost is not a burden ?
In any case, I can see no immediate reason why an operator ought not to take advantage of the usual assumed temperature procedure - you get some benefits without any angst at all..... and the data is there anyway ....
I am not familiar with the Falcon 2000 - I presume, on the basis of bp's post, that the crew can't input a false, higher OAT to command the FADEC to derate on the assumed temperature style of model ?
As to the risk ? Depends on the circumstances of the takeoff and how the numbers are crunched. It is still quite easy to schedule a derate takeoff and remain accel stop limited if the runway numbers are suitable - which is what generated some wide-eyed comment following Mutt's posts on the subject.
In practical risk terms, the continued takeoff is not really a common worry due to the gross to net margin - unless the ambient is very bumpy and the obstacle profile onerous .. and, if that is the case, why would you be even considering not using all the available grunt ?
As an example, I recall many years ago, an F27 takeoff, rated wet power, turbulent ambient, nowhere near the WAT limit, and seeing the VSI pegged at around 200 FPM (AEO) for about the first 2000 feet - and, on that occasion, I did a quick altimeter vs clock check on the VSI. A bit unusual, perhaps, but emphasises the point that derate is for those occasions when everything is going for you - the real danger here, as in any area of line operation, is the uncritical and unthinking use of a procedure - sometimes the captain has to earn his money and make a decision contrary to a normally recommended or accepted practice. Every now and again not doing so gets people into more strife than Speed Gordon.
(b) Increasing thrust in the OEI case ?
The basis of certification is that the power/thrust is set and left. While this doesn't prevent or preclude the crew's pushing the remaining throttles up for whatever reason, manual adjustment is not permitted to be scheduled for certification purposes. It is for this reason that some installations incorporate auto power reserve (by whatever name), which does the same thing without pilot intervention, and may permit an increased RTOW to be scheduled, depending on the circumstances.
The suggestion that increasing thrust in the OEI case would compromise Vmcg considerations in the case of a min V1 scheduled takeoff probably is not a major concern. While there are some provisions for scheduling thrust level versus control variations, I would not imagine that a manufacturer has considered scheduling such variation just to accommodate lower min V1 speeds, unless this is done incidentally as part of a fixed derate recertification program in which the Vmcg is revisited. Cpdude's comment re the 20 percent derate for low RTOW/aft cg takeoffs on the big bird well may involve such a consideration. It follows that, in such a case, inappropriate throttle movement within an unfortunate speed band and at an inappropriate rate, could present a problem.
Now there is one other proviso to this line of argument and, unfortunately, the example I would love to give would be too easily recognisable in some circles, regardless of sanitisation.
In the event that
(i) a particular aircraft's engines are pretty good, maybe considerably well above book, and
(ii) the engine is not a full throttle takeoff setting animal,
then there is a very real risk that a ham-fisted or panicking pilot might inadvertently overthrust the engines to such a degree, and at such a rate, that the published Vmcg or Vmca figures might be compromised significantly.
(c) Use of electronic gadgets to figure ops eng data ?
(i) Load calc checks ...
We are obliged to leave a Load Sheet so there must be some sort of paperwork involved. From a practical point of view, it is very much easier and quicker to do a quasi-independent crosscheck manually.
One operator with which I was involved over many years adopted a procedure where the paperwork was done by the relevant ground staff and then presented to the crew in the usual manner. We had run up some prayer wheel style trimsheets for the FO to use for checking purposes. So the captain would, in the conventional monotone drawl, call the data line by line, while the FO worked the prayer wheel to figure the final weight/cg intersection which could then be compared to the figure derived by the despatch people.
I defy anyone to do that sort of check using a laptop in anything like the few seconds that it took in the referenced operation. In addition, I have a jaundiced view of computers (in spite of having spent my life in a succession of mainframes, minis, and PCs) if they be used in a quick and dirty manner. In that sort of environment, the risk of data entry error has to be protected against, very rigorously, in the relevant prescribed procedure.
Me ? I started out a bit anti toward the prayer wheel option (which was being pushed by the chief pilot and the senior load controller) due to trimsheet accuracy/error considerations but went along with the idea. It took only a very short time for me to become a convert to the procedure.
(ii) RTOW figures ..
I have little concern with on-the-fly calculations where the procedure is a simple, straight flightpath with no surprises. However, and this is one of my hobbyhorses, the normal declared data (Type A and B, or inclino) is very limited when looking at the needs of the modern jet - with its comparatively very long third segment. The AFM calculation is the easy bit, which the computer makes even easier, far quicker, and a little more accurate.
The real problem, and where most of the work ends up going into (or ought to), is obtaining the profile data in the case of extended takeoffs and, very particularly, takeoffs which incorporate a turn. This is a major task for an operator's ops engineering personnel, or its subcontracted organisation and which, I am sad to observe, often is done very poorly, and sometimes, not at all. If the crew tries to figure a weight (in such circumstances) from a combination of the declared data and eyeballing the surrounds (which is about all the pilots can do in the field), then the laptop will give only a much more accurately calculated wrong answer than could be much more easily obtained by guesswork. Either answer would be equally suspect.
(iii) Use of computer in lieu of AFM ?
If we go back a way, AFM charts were derived laboriously by a bunch of people doing lots of sums, crossplots, and the like - can anyone remember using a sliderule (apart from the back of the nav computer) ? The end graphical or tabular result was workable, but often not very tidy - as anyone who has had to computerise AFM data from these older aircraft can attest.
With later aircraft, the performance is software modelled from the start of the project, and the fudge factors refined as the tunnel and flight test data come in. In respect of such aircraft, the paper data in the AFM is more for traditional nicety and, in some cases, doesn't even exist. If I recall correctly, the introduction in Australia a number of years ago of a fancy new narrow bodied twin jet caused some heart palpitations for just this reason - but the regulator and the operator apparently survived the experience.
[This message has been edited by john_tullamarine (edited 31 May 2001).]
[This message has been edited by john_tullamarine (edited 31 May 2001).]
[This message has been edited by john_tullamarine (edited 31 May 2001).]