Composite Runway Slope

[Old Smokey]

A question for others doing Performance Engineering in the area of Airport Analysis, production of RTOWs, and the writing of programmes for generating RTOWs.

The traditional application of a runway with composite slope has been to use the mean slope, as AFM data and computer programmes for generating RTOWs typically deal with one single value of slope. In the past, I too, have used mean slope, but with concern.

The runways that concern me most are the 'humping runways, i.e. an initial UP slope, traversing the hump, and followed by a DOWN slope. One runway that I deal with has a 0.5% UP slope for the first half, and a 0.7% DOWN slope for the second half. Using mean slope (0.2% DOWN), I consider to be unrealistic as Acceleration (over the UP slope) will be poorer than expected, and Deceleration over the DOWN slope during an Accelerate-Stop will also be poorer. Thus, the RTOW produced may exceed the actual maximum weight at which an Accelerate-Stop manoeuvre could be safely carried out. (I would consider a 'dipping' runway to be safer).

My solution was to rewrite the programme to do a triple computer run for the runway, one using the greatest UP slope, one using the MEAN slope, and a third using the greatest DOWN slope. The resultant published RTOW is the least of the 3 results. Yes, it is somewhat conservative, but I sleep better at night. The remaining problem is what to tell crews to do if an RTOW is invalidated, and they must resort to 'General Charts'. At present, my instruction is to use MEAN slope.

Very interested to hear other's approach to the problem.

Regards,

Old Smokey

[mutt]

As most of our aircraft manufacturer software only permits one "slope" input we generally stick with the "mean" slope.

You describe 3 takeoff calculations, what sort of weight differences are you getting? what is the takeoff calculation time requirement? Are your programs using "first principle"?


Mutt.

[john_tullamarine]

Same concerns as has Old Smokey.

Using object code provided by others does cramp one's style for doing one's own thing ...

I have done the "put the AFM charts into the computer" thing for a number of aircraft and that gives me much more convenient control over how I choose to run the analysis.

My approach has been to do the analysis on a segmented basis, matching local slope to the sums as I saw fit, although with an eye to conservatism. Fairly easy sort of algorithms to set up ..

However, to cover my delicate little posterior for the inevitable questioning at the enquiry .. I compare the results to those obtained with an average slope and use the lesser value of the two.

[Old Smokey]

mutt, John Tullamarine,

J_T, may I use one of your quotes -

I have done the "put the AFM charts into the computer" thing for a number of aircraft and that gives me much more convenient control over how I choose to run the analysis.

That saved me a lot of typing - Ditto for me. A huge amount of work, but it pays dividends, particularly when doing work for Australian customers who wants to use STODs as 'core' data, incompatible with most AFM data. The programme does the 3 runs internally, and provides the final result, there's no need to laboriously cross compare 3 sets of data at the finish.

Mutt, Although we operate from a number of runways with significant slope, these are of quite uniform slope. Fortunately, the 'humpy' runways are not too steep, the 0.5% UP / 0.7% DOWN / 0.2% DOWN MEAN, is the worst we have, and the worst penalty is of the order of 1000 Kg. Not good for economics, but I consider necessary for safety. As I put it, I sleep better at night, J_T spoke of covering his posterior at the enquiry.

The 'run time' depends largely upon the number of obstacles involved, as you would be aware, but, on average, the 'triple' run takes about 30 minutes for a FULL set of RTOWs (Less than a minute for a single calculation). What I did omit to say is that I also do a 4th run using the manufacturer's programme, and take the least of my programme's results or the manufacturer's. Usually they're the same to within a few Kg, the 'up to 1000 Kg' difference arises from comparing my programme's results to theirs in the BAD humpy runway cases.

Another advantage in using multiple slope, is when it's necessary to reduce the TOD used to optimise obstacle clearance, and, even if one is only using mean slope, the mean slope has changed for an undulating runway (is that a better word than humpy ?) when calculated over the shorter TOD to be used.

We have to pray to 3 Gods - (1) Is it safe?, (2) Is it still commercially viable although a tad conservative, and (3) Is it useable by flight crews?

My other concern still remains - What to tell crews to use when having to resort to 'General Tables ?

All inputs greatly appreciated,

Regards,

Old Smokey

[john_tullamarine]

use STODs as 'core' data, incompatible with most AFM data

.. not too sure where the problem is here .. one just converts the EOL slope to a few well placed dummy obstacles and away the program using discrete obstacles goes ... the only trick is using well-conditioned dummy obstacles so that the program doesn't do anything too stupid.

[Old Smokey]

john_tullamarine,

I should have been more specific. My programmes do the conventional calculations for discrete obstacles, but also include STOD/OCG input for Australian operators wishing to use STODs as core data (Survey limits longitudinally and laterally require considerable additional discrete obstacle data). Their desire to use STODs as 'core' data emanates from a wish to respond quickly to NOTAM changes.

The problem does not lie in the 2nd segment, but in the 1st segment. (This is the incompatability of STODs with AFM data that I alluded to). As it's impossible to know from a STOD just where the obstacle is (dummy or real), I ensure in the programme, that the 1st segment lies above the TODA and the Obstacle Clearance Plane.This requires the programme to do a bit of trigonometrical manipulation considering 1st Segment Gradient and Length, End of TODA Slope, and published STOD Gradient, to find the reduction in STOD necessary to achieve this. The end result is that screen height is achieved a few hundred metres before end of TODA, 1st segment then continues above the remaining TODA towards intersection with the STOD OCP beyond the TODA. Obviously a bit conservative, yielding a typical screen height of 44 feet (9 feet in the bank), but the best means that I consider for handling 1st segment when using STOD data. (STODs in this context include TODA and it's associated OCG).

If things start looking too conservative, then back we go to Type 'A' runway charts and full discrete obstacle analysis, the STODs go in the bin.

Regards,

Old Smokey

[john_tullamarine]

Old Smokey, mate .... have I got a deal for you ...

Have a look at doing reverse calcs on the STODA data .. dead simple trig .. although the slope intersections have a bit of scatter due to the round off involved in transforming the obstacle survey data to EOL data ... generally you can identify the STODA critical obstacles to more than adequate accuracy for the requirement ... and, then your problem goes away. (As an aside for a giggle .. the difficulty comes with roller coaster runways ...)

But, why bother ? .. just give the surveyor a ring and ask nicely for the obstacle data ... can't recall the last time I got knocked back or charged more than a nominal amount to cover direct expenses. And, of course, one always drops in to say "hi" and buy the good folk a beer when one is in town as a way of saying "thanks".

Type A aerodrome folks sometimes tend to be a bit more mercenary as they need to recover the cost of the Type A work.

In my view, while you are being less conservative than the sledgehammer approaches of either bringing the first segment distance into the TODA/STODA or matching first segment gradient to the EOL surface ... you are being more conservative than is warranted in those cases (most) where you can do a sensible reverse analysis.

[Old Smokey]

john_tullamarine,

Ah, the good old reverse engineering trick - Thank you J_T, a very useful tool and, from what you say, more cost effective than Type 'A' analyses. Actually, I frequently use reverse engineering with PANS-OPS minima, removing the PANS-OPS margins, and re-adding the FAR25 / CAO 20.7.1B margins, useful if obstacles are not a great problem.

Not looking gift horses in the mouth, but is the STOD obstacle data a complete series (as per Type 'A'), or just the most critical single obstacle generating each STOD? I have a tame surveyor in mind as a guinea pig.

As stated, my customer prefers to use unadulterated STOD data as far as possible in order to react quickly to NOTAM changes, but this is a useful trick to add to my toolbox for those occasions when the 1st segment technique which I use is just a bit too conservative, and discrete obstacles must then be considered.

Now, as I was saying about composite runway slope.......

Thanks, and Regards,

Old Smokey

[john_tullamarine]

Perhaps I should apologise a tad for waxing too lyrical before ...

Based on the STODA/TODA data, one cannot presume to have identified all the interesting obstacles. Rather, the reverse calculation determines the intersections of the various slope surfaces and one ends up with a less restrictive polygon style of surface.

For each STODA surface, the surface will be determined by the relevant critical obstacle .. this may be the same obstacle for one, some, or all surfaces as the case may be.

Often, there will be only one or two significant obstructions (often the perimeter fence or tree line (or presumed vehicle) along the road and it is usually pretty obvious from the analysis if this is the case.

However, one must still ensure that one postulates a composite surface defined by the polygon by putting in a few dummy obstacles along the surfaces. The end result is a set of "obstacles" which may, or may not, identify the actual obstacles, but defines a safe surface upon which to base a quasi-discrete obstacle takeoff analysis. Generally far better than using the base slope data as the aircraft can take advantage of successive lower slope surfaces.

The trig is straight forward but there are a few traps in setting up the analysis .. suits spreadsheet calcs quite nicely.

So far as reacting to NOTAM changes, this approach works a treat as the whole exercise is based solely on RDS information. Just need a PC to hand to do the sums and run the takeoff analysis. Not suited to pilot calcs via general takeoff data which remain tied to matching available aircraft gradient to available declared surfaces ..

[mutt]

Gentlemen, what is STOD data?

Mutt.

[MkVIII]

Mutt,
This is the Supplementary Takeoff Distance. STOD is the length of the runway available for the ACCELERATE/GO from V1, taking into consideration any obstacles which lie off the end of the runway. STOD factors can restrict TORA, but not ASDA, ergo, STOD restrictions will only apply to ACCELERATE/GO, not ACCELERATE/STOP.

[john_tullamarine]

New-speak for EOL and however many other like terms.

To qualify our Spitfire loving colleague's observations

(a) the x percent STODA distance is from start TODA to a point from which an obstacle clear gradient of x percent exists


(b) STODA has nothing to do with TORA (as this relates only to the declared length of seal) but merely provides a data table matching reduced runway lengths against corresponding obstacle clear gradient surfaces. How this data may be used by the ops engineer or pilot is variable.

[Old Smokey]

J_T,

Got the idea, thanks! It would seem that the process of re-inventing the wheel continues, we've gone from Obstacle Clear Planes to Obstacle Clear Polygons. I've got a nice mental picture of it, from humping runways to humping Obstacle Clear Planes in just 12 posts!

I've often considered using the resultant polygon from putting together a series of STODs, but a tad concerned for the "unconsidered" obstacles lying between the various standard gradients. The people that pay my salary are demanding subservience to their wishes over the next 5 days, might have to put that one on ice with Mutt's beer until I return.

Best Regards,

Old Smokey

[MkVIII]

John,
I thought EOL was the lessor of ASDA, STOD, and TODA, minus any line up allowance? So, in essence, EOL can be ANY of the three, with the MOST limiting distance being the EOL?

STOD data surely WILL/MAY restrict TORA - considering that the obstacle gradient may impugn directly on the physical TORA (not ASDA naturally, since we are considering the GO case)

Again, all genuine questions!

[john_tullamarine]

Old Smokey,

.. I really want to make a politically incorrect and inappropriate comment .. but I mustn't .....


To address the real obstacles, one puts enough dummy obstacles in between the intersections (and especially after the final intersection) to suit matching the AFM gradients to the polygon thereby forcing the net flight path to stay about the polygon. These dummy obstacles are defined to lie along the relevant polygon surface .. so the discrete obstacle program is forced not to dip below the surface .. QED no fly into ground problem.

End result is no less "safe" than matching gradients but, especially for close-in obstacles, .. is far less conservative and may produce significant RTOW benefits .. not always, but, for small close-in obstructions, the benefits can be quite significant .. all a case of horse for courses.

Not flying these days, I don't have to rush off on multiday tours .. as a good little contractor, I just have to work 24/7 except for the occasional day off every 3 years for good behaviour ... I miss the flying .. but c'est la vie ... might have to go do a circuit or two sometime and see if I can still stay right side up....


Mk VIII,

Think EOL = STODA .. just a name change. You may have a different definition for some specific purpose, but the old AIP usage was equivalent to STODA - if there is any difference, I am not aware of it and it would be fairly subtle .. perhaps Overrun can comment if he is following this thread ?

TORA has nothing to do with STODA. TORA is there solely to constrain clearway for the TODA case.

The airport authority declares an available clearway but, in many cases, a given aircraft can't use it all ... reason being that we need to make sure that the bird is off the ground before it runs out of seal and into the dirt .. recall that clearway can extend a significant way beyond the end of the runway. Depending on the rules applicable to the operation, only 2/3 or 1/2 of the airborne distance from liftoff to screen may be over the clearway. This restriction is built into the TORR calculation.

In the STODA case, the TORR-limiting calculation ceases to be limiting at all as the available TOD (STODA) is less than the declared TORA. Reflect upon the picture ... TORA is fixed by the physical runway dimensions. For TOD calcs based on STODA the actual TOR will reduce but this has naught to do with TORA

Questions is what questions forum is all about ...

regards both,

JT

[MkVIII]

Hmmmm. Humping runways and planes....

Me thinks Old Smokey ihas "SOMETHING" on the brain... :p

John - it's more fun if you DON'T stay right side up! :ok:

[john_tullamarine]

A long time since I have done any aerobatics in the aircraft .. good fun in the sim as a UA training exercise, though .. and our posts have overlapped .. some comments on your previous post in my previous post.

[MkVIII]

Ah, thanks John - I see where I was confusing terminology...

Basically, what I was getting at was that the available TOD/TOR was reduced (whereas the TORA is fixed and finite).

It all made sense in my head, but when that translated to "paper"....

[john_tullamarine]

Peace, brother .. I have that problem all the time .. which is why I re-read my posts after posting and often amend them several times until I am happy with the words ..

Even then I have been pulled up by lynx-eyed detectives amongst our sandpit colleagues at least once that I can recall for inadvertant technical stupidity ....

[Old Smokey]

John_Tullamarine, sorry that it took some time to respond to your “polygonic obstacles” suggestion, but the powers of darkness that control my roster decreed that I be in other places.

Your suggestion does have a lot of merit. I’ve always been extremely reticent in any activity which might be construed as interpolation between STODs, because of the “unconsidered” obstacle that might lie between them. The diagram illustrates my concern –


http://www.gunboards.com/forums/uploaded/PPHS/20052255186_stods.jpg

The diagram shows the TODA with it’s associated OCG, and a 3.3% STOD, essentially two STODs. Obstacle A has been used by the surveyor in establishing the TODA OCG, Obstacle C has been used in establishing the 3.3% STOD. Obstacle D is of no concern to the STODs, but will have to be considered for the 3rd segment acceleration altitude. My concern is for Obstacle B, which has not been considered for either the 3.3% STOD or the TODA OCG, if, however, we were to interpolate between these 2 STODs (as shown by the 4.1% broken line in the example), we will collide with Obstacle B. For this reason, any RTOWs I’ve created using multiple STODs have had an interpolation prohibition between data elements imposed. Your suggestion of the creation of “Phoney” obstacles at OCP intersection points, suitably labeled the “JOHN_T POINT” in your honour, may well overcome the unconsidered Obstacle B. I cannot conceive of any circumstance where Obstacle B protrudes above the polygonic series of OCPs, can you?

But now to the unconsidered Obstacle D, which existence we don’t know of from STODs or the RDS. Do we consider one final obstacle at the lowest published OCP at the Survey Limit? For a 1.6% STOD and a 15000M Survey Limit, that makes a final obstacle of 787.4 ft, with a corresponding acceleration altitude of 1216.1 ft, pretty high! OK, I’m being a bit nit picky here, by that time we’ve passed most nominal acceleration altitudes anyway (400, 800, 1000 feet, whatever!) and are already ‘down and dirty’ looking at discrete obstacle analysis.

All good value stuff John_T, thank you! Still…because I don’t know where the obstacles really are, I still have to keep 1st segment above the Runway and the OCG, be it the STOD Gradient, or the Gradient to the “Phoney” obstacle. Much thinking needed about this new can of worms you’ve handed me.

Now, as I was saying about composite Runway Slope…….

Regards,

Old Smokey

[john_tullamarine]

Old Smokey,

First, my PM box was full the other day .. if you had sent anything, it would have bounced. All OK now.

Provided one stays above the polygon, there can be no situation where the profile is compromised as one can use any of the declared surfaces for the take off calculations.

The only problem is due to round off in the survey to surface calculations (inclino surveys are not common .. normally a conventional survey is used to determine obstacles) .. which are used to calculate the surfaces. However, the calculations are rounded off for publication. When the reverse calculation is done, the round off usually results in numerous intersections, although it is usually fairly obvious what the story is .. simple solution is to use the critical polygon and accept a bit of extra conservatism.

Acceleration level surface cannot be inferred from the surface data and needs other input to determine. In the case of a quick calculation and no other available data, one can only keep the acceleration segment above the polygon ... normally unduly conservative but gives the quickest calculation.

If one uses data from let down plates, be wary of

(a) trees and such like which are not normally considered.

(b) cultural obstructions such as buildings etc

(c) information panels overlying critical obstacles .. has been known to occur and is a tad awkward ...

Usually one can ferret out some commercial surveys for many places .... EOPM, published charts, whatever.

[Old Smokey]

john_tullamarine,

Many many thanks. Have already used a few worms from the fresh can of worms you gave, a wee bit of optimisation for those customers desirous of using STODs as core data coming up.

Thanks for the warnings re trees, cultural obstacles etc., "my" CASA guy already thinks that the assumed trees etc. that I use are a tad conservative, but that makes him happy, and I sleep better at night too.

PM coming your way in the next few days,

Regards,

Old Smokey

[john_tullamarine]

The AirServices procedures designer chaps can point you in useful directions for tree heights ... if you don't have specific contacts, I can pass these to you... OzExpat, likewise, would be a useful source.