View Single Post
  #3  
Old August 9th 04, 10:43 PM
Stan Prevost
external usenet poster
 
Posts: n/a
Default

I'm replying to my own thread rather than starting a new one on the same
topic.

I went back to the "Must File To An IAF" thread and excerpted some
statements that are relevant to the issue I am trying to clarify through
discussion here. I'm not picking on or challenging anyone and I am not
debating filing to an IAF. I am trying to understand the more general issue
of how are fixes/airports/navaids/waypoints handled in various computers
associated with flight in the US National Airspace System, and how pilots
can file flight plans that suit their needs as well as the needs of ATC,
while understanding why.

First I will present the excerpts and then present my questions.

Sydney:
Fact: filing a flight plan to a fix not in the computer database of
the originating facility will cause the computer to stop processing
the flight plan. then the controller has to sort it out. This is
particularly a problem if the pilot has filed "direct" and ignored
the AIM suggestions about including navaids in each center's airspace
on their direct routing.

Newps:
There's no sorting out. If the flight plan comes out of my strip printer
then the computer won't have a problem with it.

McNicoll:
Unless the IAF is also part of the enroute structure it is unlikely to be
stored in the flight data processing computer. Filing one will cause your
flight plan to be rejected at some point, until someone corrects it by
removing the filed IAF!

Sydney:
If the IAF is not an H-class VOR, it's not likely to be in the ATC
database of the originating ATC facility if you're making a trip of
any duration, so filing to an IAF only bolixes the works.

McNicoll:
The IAF is probably an LOM that is not stored in the computer so filing it
will cause the flight plan to stop processing at the last good fix.


Sydney:
But it's still not necessarily a good idea to file to an IAF, since the ATC
facility where the flight originates may not have said IAF in their
database.


McNicoll:
In most cases where the IAF is not part of the enroute system the flight
data processing computer will not accept it anyway.


Sydney:
If you're not filing via airways, and your flight originates outside
the ATC facility who "owns" that IAF, the harm is that the ATC computer
will very likely not recognize that IAF and will stop processing your
flight plan at that point. So if you insist on putting an IAF in
block 8, make sure there are several more nationally-known waypoints
defining your route of flight.


Some general themes running through the above comments and other
discussions:

1. A flight plan may contain fixes that are valid but may not be recognized
by the computers at various ATC facilities along the route of flight.

2. A flight plan containing any valid fixes can be successfully filed
through FSS or DUAT/S but not necessarily by a controller, whose computer
may not recognize some of the fixes.

I believe it to be the case that a flight plan filed through FSS or DUAT/S
is routed to a center computer, which processes the flight proposal using
secret algorithms and decides whether to accept the plan or to generate a
new route (such as a preferred route), and then sends the flight plan to the
ATC facility responsible for the point of origin of the plan, where a flight
proposal strip is printed. This strip will have the information to be given
to the pilot in his/her clearance, and whether it is "as filed" or "full
route clearance". The clearance will include all fixes in the route,
whether or not they are stored in the computer of the initial ATC facility.
Once the controller at the initial facility "departs" the flight, flight
progress strips are then printed out down the line along the route of flight
at the facilities to which the aircraft will be handed off to. Those strips
also include the route, or at least the route information is accessible to
the controller in the computer, whether it is "understood" by the computer
or not. I hope this is correct so far.

Another theme running through the previous comments is that the computer at
each ATC facility along the route does some kind of processing on the flight
plan, but upon encountering a fix that is not in its database, will "stop
processing" at the last recognized fix. This supposedly results in somehow
bollixing up the works. I think it is being said that the controller will
be unable to determine the route of flight through his/her airspace, and
some examples of actual experience were given to illustrate that. Steven
even said the flight plan will be "rejected at some point" until someone
removes the offending fix (which is valid but unrecognized). Newps said
that if it prints on his printer, the computer won't have any problem with
it. I'm not sure how to reconcile those two statements, they could suggest
that an unrecognized fix will cause a flight progress strip to not print
out.

Well, I really don't understand. First, I don't know what kind of
"processing" is performed by the ATC computers, and I don't know what is
meant by "stops processing" or "rejected". When the computer *successfully*
processes the plan, what is different from what happens when it "stops
processing" at some point? Does something different show up on the radar
scope, does an error message occur, are F-16s launched against the offending
aircraft, or what?

Further, I don't understand why, in the previous thread, the emphasis was
placed on enroute fixes (in particular, an IAF) not being recognized by
computers along the way. If the fix were omitted, then wouldn't the same
problem arise with the destination airport? Why is it not the same
situation with just GPS airport-to-airport direct, with no enroute fixes?
Do all the computers store all the airports? I know that when I file direct
to Podunksville Muni several centers away, nobody along the route seems to
have any idea where that airport is, but nothing is bollixed up. Maybe that
is because I generally file through DUAT, and DUAT includes the lat/long of
the airport and the computers can process that. If I include an arrival
fix, DUAT puts in the lat/long of that fix rather than the airport. I don't
know if FSS inserts lat/long like DUAT does.

I performed an experiment with DUAT. I filed (and deleted) several flight
plans, from an airport in Memphis Center airspace to an airport in
Minneapolis Center airspace, with Indianapolis and Chicago center airspace
in between. This is a flight I commonly take, usually GPS
airport-to-airport direct, with no problems (that I know about).

a. Airport (ZME airspace) direct airport (ZMP airspace). DUAT inserted
lat/long of destination airport in route.
b. Airport, VOR in Minneapolis Center airspace, airport. DUAT inserted
lat/long of the VOR.
c. Airport, VOR in Indy Center airspace, airport. DUAT inserted lat/long of
the VOR.
d. Airport, VOR in Indy Center airspace, VOR in Minneapolis Center
airspace, airport. DUAT inserted lat/long of the VOR in Indy Center
airspace.
e. Airport, VOR in Memphis Center airspace, VOR in Indy Center airspace,
VOR in Minneapolis Center airspace, airport. DUAT inserted lat/long of the
VOR in Indy Center airspace.

Assume that any of the ATC computers along the route can process a lat/long,
and that ATC computers store only fixes within their center's airspace. Then
any of these flight plans would have been fine for Memphis Center (and
presumably approach control facilities delegated Memphis Center airspace).
I say that because the computers in Memphis Center airspace would have a
recognized waypoint (lat/long) farther along the route to allow computation
of the route through Memphis Center airspace. I'm not so sure about
subsequent facilities. For example, in Chicago Center airspace, the
adjacent airspace areas are Indy Center and Minneapolis Center. In Cases c,
d, and e, there would be no recognized waypoint or lat/long in Chicago
Center airspace or beyond it. This one experiment suggests that DUAT
generates flight plans that favor the ARTCC in whose airspace the flight
plan originates.

So I reversed the route and reran the experiment.

f. Airport (ZMP airspace) direct Airport (ZME airspace). DUAT inserted
lat/long of destination airport in route.
g. Airport, VOR in ZMP airspace, Airport. DUAT inserted lat/long of
destination airport in route.
h. Airport, VOR in ZMP airspace, VOR in ZID airspace, VOR in ZME airspace,
airport. DUAT inserted lat/long of VOR in ZID airspace.

This supports that the DUAT plans favor the originating ARTCC.

I repeated the experiment on DUATS. For Case a, the result was identical.
For Case e, DUATS did not insert ANY lat/longs. That's all I ran.

(Another difference noted is that DUAT would not let me have more than one
flight plan on file using the same A/C, airports, and times. DUATS had no
problem with it.)

It would be useful to know more about the capability of center and approach
control computers in terms of their databases of fixes. Do they all store
some subset of the total database, and is the way the local database is
constructed uniform across facilities, or is it variable because of
equipment, or local policy, or what? What will work for all of them,
besides lat/long? Have to be careful about putting too many lat/long or FRD
fixes to define the route, because Newps says they "fix" those kind of
flight plans when they see them, or not enough because Steven says that
offending fixes (IAFs at least) are removed.

What I would conclude from my experiment is that whenever going from Fix A
to Fix B crosses one or more center boundaries, including the lat/long of
Fix B will always work, no matter how many center airspaces it crosses.
This might be somewhat tedious to determine. The AIM recommendation to
include at least one waypoint in each center airspace would also seem to
work, although DUAT/S does not do that. I also wonder the reason behind the
AIM recommendation that a waypoint be no further than 200 nm from the center
boundary. Maybe that has something to do with the rules for selecting fixes
to be stored in a center's computers, that it stores fixes within its own
airspace plus 200 nm around it?

I can easily see that pilots might have different experiences depending on
what service they used to file their flight plans.

Any help in getting this sorted out and understood will be appreciated.

Regards,
Stan