If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
|
#1
|
|||
|
|||
NAS and associated computer system
Snowbird wrote: What can happen -- what's happened to us -- is that the tower controller doesn't worry his head about your flight plan. Yes, but it has to be typed in and accpeted by the computer. At all the class C airspaces all the controllers work all the positions at various times thru the day. You don't drop a handwritten strip down the tube and expect the radar controller to handle it. He figures the tracon's gonna vector you and the center's gonna reroute you anyway so why should he sweat. He says "cleared as filed". The tower guy says cleared as filed if the strip tells him to say cleared as filed. Now you're handed off to Tracon, and he looks at your flight plan and realizes he has no clue where you're going. Have that happen a lot. And the location identifier book is all the way over there. So you say resume own nav and see where he goes. If I want to nail it down to 50% of the sky I'll look at the final altitude and see which way he's going. But he figures you'll be out of his airspace before he sorts it out, so let the center controller sweat it. He queries, "Grumman 12345, say on-course heading", you respond, and that's sufficient for him. 10 minutes later, you're handed off to Center. Yep, do that too if you're a slow mover and there's traffic. Well, the next Center isn't going to be fobbed off with "on-course heading blahblahblah" on the handoff, so the buck stops with the first Center guy (this is our experience, mind, YMMV). The center has the same route on his strip as I have on mine. He will move you for traffic, not because he doesn't know where you're going. So if Newps (sorry to pick on him) transposes two numbers and has you headed in the opposite direction than you intend to fly, no one will know until you take off from a non-towered airport headed west with the controller having carefully arranged your separation believing you're headed eastbound. No controller looks at a set of lat/lons and says to himself..."Flying east today." A lat/lon is for the computers benefit, it has zero value to a controller. |
#2
|
|||
|
|||
"Snowbird" wrote in message m... "Stan Prevost" wrote in message ... I did not intend to assert that only H-class VORs are likely to be recognized nationwide -- that's not true. It seems to vary from center to center. Any VOR on an airway is a fairly good bet some places. big snip OK, I see that I interpreted your comments about H-class VORs too broadly, and I now understand your meaning better. It would seem logical to me (for whatever that has to do with anything) that any VOR used to *define* airways, low- or high-altitude, would be recognized by any computer that has anything to do with flights on the airway structures of the National Airspace System. My husband would say something like "Stan, this is the federal government. You're expecting it to be logical. There's your mistake. There's where you're going wrong". (since he rassles federal regs for a living, he has a right to an opinion). :-) Yep, but you will notice that my parenthetical remark disclaimed the application of logic to a gov't system. What I *think* is going on, though, is that the airway itself is understood by the computer, but the specific navaids which define it in, say, ZKC airspace, might be unknown to the computers in Miami Center. So if you route by airways, you're gold, but if you pick a non-H class VOR two centers away as one of the few waypoints defining a direct route, it might not be recognized even if it's on an airway. I await further enlightenment on this point. Me too! The first thing is to understand the controller's needs for route definition, specifically for a direct flight for this discussion. One might expect that the controller would be concerned only with the route through his airspace, so he couldn't care less about the route definition way down the line. Does he need to be able to make my course line appear on his radar scope all the way through his airspace? Or does he just need a short-term projection of my track using radar for present position, direction, and speed? Probably one need is to be prepared to handle radar failure. In nonradar procedures, I think they try to move us all onto airways, and to do this, the panicked controller needs to know which airways to move us onto that keep us going in the proper general direction and out of his airspace (or maybe the computers suggest new airway routing). So how does knowing one VOR-based fix in his airspace do that? Does he have his computer draw a line on his scope from present position through the fix, so that he can then pick airways that approximate that route? The next thing is to understand what the ATC computers are capable of and how much variation there is among them, in terms of storage/knowledge of fixes. But eventually, no matter how well we understand those things, we will come back to the old oft-debated issue of no matter what you file, you will get something different or will get major reroutes, so you might as well file direct airport to airport. I am sure this is more true in some areas than others, based on my own experience, and for frequently-flown routes, one can eventually learn reliable routing. Up through the northeast corridor, I always get reroutes. In the east-central US, I can file from Alabama to northern Lower Michigan airport-to-airport direct and always get cleared as filed with no reroutes. I do this frequently. Many times, flying to other destinations, I have tried to tweak my route to include some major VORs, only to get an in-flight clearance direct to destination airport. 3. Newps said that his FDIO won't accept intersections that are not in his center's airspace, but that filing through DUAT/S and AFSS does not have that limitation. I would expect that virtually all general aviation IFR flight plans are entered via DUAT/S or FSS, excluding local clearances to punch through a layer or for instrument practice. And back to Sydney's comment quoted above, I don't know what she means by the "originating ATC facility". I apologize for being unclear. I wasn't talking about filing a flight plan. As you say, that's usually through FSS or DUATS. DUATS will accept a flight plan direct from an obscure intersection in CA to an obscure intersection in FL. So will FSS as far as I know (I haven't tried). Duats will insert one lat-long per center. FSS doesn't seem to. When I file through DUAT, it doesn't do one lat/long per center, it only does the final fix. What I mean by the "originating ATC facility" is the ATC facility you talk to after you leave the ground, or the first Center you talk to. Thanks, I understand your reference now Or maybe she means the center through which the flight plan is routed for processing after it is filed, and I really don't know what happens there. That's what I mean. I really don't know what happens there, I just know what happens to me . Now if you've filed airway routing, I'm told an unrecognized intersection or waypoint at the end of the route is no big deal. The flight plan gets processed to the unrecognized point. The first controller will know which way you're going, and by the time it matters, the ATC computer will recognize it. Which is why Don Brown and some others favor airway routing, and I have to say I'm coming around to that viewpoint myself. It's mostly an issue if, like many pilots these days, you file GPS direct but feel you're making the skies safer or your karma cleaner or something by adding the IAF from which you plan to shoot an approach to your route. Or, let's say you've read the AIM and you virtuously add a waypoint defining your route within 200 nm of each center boundry. Let's say it's a VOR. big snip I don't see any difference between filing airport-IAF-airport vs airport-airport, in terms of fix recognition and controllers knowing your route. If the IAF (or other nearby fix) is there, it likely won't be recognized by a distant computer (another center's airspace). But neither will the airport. Maybe some airports are in all computers, but going into Podunksville Muni, forget it. "N8158Y, say on-course heading." (Having lat/long in the flight plan for the final enroute fix or for the destination doesn't seem to change getting the heading request.) In either case, at the originating end and along the way, the controllers will be in the dark about your route, but the situation resolves itself as the flight nears its destination. What can happen -- what's happened to us -- is that the tower controller doesn't worry his head about your flight plan. He figures the tracon's gonna vector you and the center's gonna reroute you anyway so why should he sweat. He says "cleared as filed". Now you're handed off to Tracon, and he looks at your flight plan and realizes he has no clue where you're going. But he figures you'll be out of his airspace before he sorts it out, so let the center controller sweat it. He queries, "Grumman 12345, say on-course heading", you respond, and that's sufficient for him. 10 minutes later, you're handed off to Center. Well, the next Center isn't going to be fobbed off with "on-course heading blahblahblah" on the handoff, so the buck stops with the first Center guy (this is our experience, mind, YMMV). This is when we, as pilots, get to learn by trial and error which waypoints and airports aren't recognized by different Center ATC computers as the controller says "um, Grumman 12345, can you give me the lat-long for India One-Twelve, or a VOR near it? No, I don't have that one...can you give me a VOR on your route of flight, within my airspace?" Needless to say, if ATC is busy, this totally lacks amusement value for them. If ATC isn't busy but the wx is challenging, it lacks amusement value for us. One would think that the DUAT/S systems were designed to only transmit flight plans to centers that would be acceptable to centers, in terms of recognizability of waypoints. There you go, expecting the federal government to be logical again. That's where you're going wrong. That's your mistake. Yeah, there's that logic thing again. But, joking aside, I really do expect that the DUAT/S contractors operated to an interface specification of some kind in designing their systems, and do not output data that will not be understood by the receiving computers. It seems to me that a US pilot filing domestic IFR through DUAT/S or FSS is safe using any valid identifiers s/he wishes, in terms of having the flight plan accepted and properly processed by the NAS computers. What do you mean by "safe", Stan? (see above) If you mean, ATC will understand which direction you're going and how your route is defined provided you use any valid identifiers accepted by FSS or DUATS, IME that's just not so. Perhaps a poor term, but I meant it as I said, that the flight plan will be accepted and properly processed by the NAS computers. To clarify my meaning, I understand that the flight plan is routed from DUAT/S or FSS to the center computer having jurisdiction over the departure point. That machine looks at the proposed route, applies some secret algorithms and decides whether to accept the route or to discard it and generate a new route, maybe a preferred route. I meant that a flight plan accepted by DUAT/S or FSS will not be rejected by the center computer because of an unrecognized waypoint. It may be the case that this computer that processes proposed flight plans is completely unrelated to those that assist (?) controllers move airplanes. It may be the case that the former has a complete database and the latter do not. I'm obviously doing a lot of guessing here, but we ought to be able to reconcile things. FSS and DUAT/S plans do not get rejected because of unrecognized waypoints, but all of us have experienced that enroute controllers do not have access to a complete database. That suggests two separate systems. Stan |
#3
|
|||
|
|||
Stan Prevost wrote: The first thing is to understand the controller's needs for route definition, specifically for a direct flight for this discussion. One might expect that the controller would be concerned only with the route through his airspace, so he couldn't care less about the route definition way down the line. Does he need to be able to make my course line appear on his radar scope all the way through his airspace? Course line? What course line? Or does he just need a short-term projection of my track using radar for present position, direction, and speed? Ain't got that either. Probably one need is to be prepared to handle radar failure. Yeah, right. If the radar fails completely at a busy terminal airspace you're screwed. We all are. The controller will attempt to knock the cobwebs off his long unused nonradar procedures but the reality is traffic comes to a grinding halt. In nonradar procedures, I think they try to move us all onto airways, and to do this, the panicked controller needs to know which airways to move us onto that keep us going in the proper general direction and out of his airspace (or maybe the computers suggest new airway routing). In a suprise nonradar situation I would call the center to see if a flight on a direct clearance is in radar contact. If so then he can stay on his direct route. But this being Salt Lake Center they don't much care if an aircraft is in radar contact so the aircraft would most likely stay on his direct route. So how does knowing one VOR-based fix in his airspace do that? I have a map. Does he have his computer draw a line on his scope from present position through the fix, so that he can then pick airways that approximate that route? You don't go making up airways. In this situation you would give a guy a heading to join an airway and reclear him via that airway. Separation would instantly go 100% vertical, it's the easiest one to apply. But eventually, no matter how well we understand those things, we will come back to the old oft-debated issue of no matter what you file, you will get something different or will get major reroutes, so you might as well file direct airport to airport. 99.9% of IFR flights out of Billings are as filed, so this is going to depend on where you are. I am sure this is more true in some areas than others, based on my own experience, and for frequently-flown routes, one can eventually learn reliable routing. Up through the northeast corridor, I always get reroutes. In the east-central US, I can file from Alabama to northern Lower Michigan airport-to-airport direct and always get cleared as filed with no reroutes. I do this frequently. Many times, flying to other destinations, I have tried to tweak my route to include some major VORs, only to get an in-flight clearance direct to destination airport. Minneapoils and Salt Lake give a lot of direct and vector to direct clearances. Now if you've filed airway routing, I'm told an unrecognized intersection or waypoint at the end of the route is no big deal. The flight plan gets processed to the unrecognized point. The first controller will know which way you're going, and by the time it matters, the ATC computer will recognize it. Which is why Don Brown and some others favor airway routing, and I have to say I'm coming around to that viewpoint myself. Airway routing is necessary in really busy airspace because right now we have no better, more efficient way of doing things. Get out into the other 75% of the country and direct routings are the norm. I don't see any difference between filing airport-IAF-airport vs airport-airport, in terms of fix recognition and controllers knowing your route. If the IAF (or other nearby fix) is there, it likely won't be recognized by a distant computer (another center's airspace). But neither will the airport. Maybe some airports are in all computers, but going into Podunksville Muni, forget it. "N8158Y, say on-course heading." (Having lat/long in the flight plan for the final enroute fix or for the destination doesn't seem to change getting the heading request.) In either case, at the originating end and along the way, the controllers will be in the dark about your route, but the situation resolves itself as the flight nears its destination. You also need to understand what I see as an approach controller. The strip that prints out of your arriving flight does not have your cleared route on it. All it has is the destination airport and the time you will be there. I don't need to know or even care what you filed or were cleared for. You're landing here and you will be vectored as such. |
#4
|
|||
|
|||
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 |
#5
|
|||
|
|||
Stan Prevost wrote: 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. No such thing happens. If the strip prints out of the computer it will work for the entire route. There is never a point where the computer throws up its arms and says screw it, where some action is required by the controller to keep the flight active. I think it is being said that the controller will be unable to determine the route of flight through his/her airspace, That can happen if you file direct and the controller doesn't recognize the destination airport. However the only controller that may really be in the dark is the first one because in all subsequent sectors the plane is on a straight line to his destination. You may not know where that is but you know about where it is because he is going directly there. 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". It means nothing because it doesn't happen on an active flight plan. If I try to make an ammendment and the computer doesn't recognize the fix then it will just reject the ammendment but the original active flight plan remains in effect. When the computer *successfully* processes the plan, what is different from what happens when it "stops processing" at some point? It doesn't, don't worry about it. 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? No. My computer stores the airports in my center and some big airports in the other centers. 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. Exactly. If your flight plan was originally accepted by AFSS or DUATS then it will work along your entire route. It would be useful to know more about the capability of center and approach control computers in terms of their databases of fixes. The approach controls don't have their own computer databases of fixes. Everything runs by modem thru the center computer. because Newps says they "fix" those kind of flight plans when they see them, We offer to get rid of the garbage in the flight plan. Sometimes they want to keep it in there for training but most of the time they are happy to just go direct airport to airport. Any help in getting this sorted out and understood will be appreciated. Now, go to your nearest TRACON and get a tour. Then ask the controller to file some flight plans thru his FDIO and you will get a better understanding and you will see the computer accept some routings and reject others. |
#6
|
|||
|
|||
"Newps" wrote in message ... If the computer doesn't recognize a fix it won't accept it. True only if the fix is within the processing center or the first fix outside. To make matters even more confusing you can call AFSS and get a plan into the computer that my computer will not take. No, he can't. And my computer will print that flight plan and it will work normally. No, it won't. For example when I fly back to the Minneapolis area I always land at Anoka County, ANE. You can call Great Falls AFSS(or use DUATS) and file your flight plan to ANE and it will print out in front of me. I, however, cannot type in the same flight plan because my computer does not recognize ANE. Wrong. What the computer accepts or rejects does not vary with the source of the flight plan. |
#7
|
|||
|
|||
"Stan Prevost" wrote in message ... OK, so all the concerns about an IAF or other waypoint not being recognized by ATC computers will not result in the pilot being surprised by a clearance that does not include the waypoint. The biggest surprise would be to a pilot air-filing and the controller, like you, reporting back that the computer does not recognize one waypoint on the route attempting to be filed. Then Plan B would have to be formulated, but this is still early in the game. Easily remedied. Just include a good fix outside the originating Center on or near the desired route. If you can provide the coordinates of the offending fix they can be entered just prior to it. The flight plan will then process just fine and no alteration of your route is needed at all. |
Thread Tools | |
Display Modes | |
|
|