Comments for ATC Freqs http://atcfreqs.com/wpblog Observations of an FAA Enroute Air Traffic Controller Thu, 02 Sep 2010 06:05:41 +0000 hourly 1 http://wordpress.org/?v=3.0.1 Comment on More Grand FAA/DOT Schemes by John J. Tormey III, Esq. http://atcfreqs.com/wpblog/?p=3954&cpage=1#comment-572 John J. Tormey III, Esq. Thu, 02 Sep 2010 06:05:41 +0000 http://atcfreqs.com/wpblog/?p=3954#comment-572 I've got a better idea. It's called: www.RandyBabbitt.net John J. Tormey III, Esq. Quiet Rockland I’ve got a better idea. It’s called:
http://www.RandyBabbitt.net

John J. Tormey III, Esq.
Quiet Rockland

]]> Comment on Protection from ERAM by The ATC Freq http://atcfreqs.com/wpblog/?p=3844&cpage=1#comment-569 The ATC Freq Sun, 25 Jul 2010 20:07:13 +0000 http://atcfreqs.com/wpblog/?p=3844#comment-569 Thanks for that additional information, George! Thanks for that additional information, George!

]]> Comment on Protection from ERAM by George http://atcfreqs.com/wpblog/?p=3844&cpage=1#comment-568 George Sun, 25 Jul 2010 19:53:41 +0000 http://atcfreqs.com/wpblog/?p=3844#comment-568 A national patch was released to all Host sites to protect the system from a flood of duplicate flight plan (fp) messages. The fix doesn’t address ERAM sending a flood of duplicate FP’s. Once two ERAM sites are up and talking to each other over interfacility communication. The flood of Fp’s will prevent other messages being received in a timely manner. For instance Handoff’s or in the worst case scenario a conflict alert with another facilities track in the process of being handed off and still in crosstel status. A national patch was released to all Host sites to protect the system from a flood of duplicate flight plan (fp) messages. The fix doesn’t address ERAM sending a flood of duplicate FP’s. Once two ERAM sites are up and talking to each other over interfacility communication. The flood of Fp’s will prevent other messages being received in a timely manner. For instance Handoff’s or in the worst case scenario a conflict alert with another facilities track in the process of being handed off and still in crosstel status.

]]> Comment on More Signficant ERAM Problems by SkyCopATC http://atcfreqs.com/wpblog/?p=3355&cpage=1#comment-566 SkyCopATC Fri, 16 Jul 2010 12:46:50 +0000 http://atcfreqs.com/wpblog/?p=3355#comment-566 George - thanks for your in-depth explanations. I'd be interested in discussing ERAM architecture in more detail if you have time. My email is skycopatc at yahoo dot com. Thanks! George – thanks for your in-depth explanations. I’d be interested in discussing ERAM architecture in more detail if you have time. My email is skycopatc at yahoo dot com. Thanks!

]]> Comment on ERAM Under the Radar by AppDev http://atcfreqs.com/wpblog/?p=3611&cpage=1#comment-565 AppDev Mon, 05 Jul 2010 14:05:20 +0000 http://atcfreqs.com/wpblog/?p=3611#comment-565 It's easy for system architects to see signs of a sick project in ERAM, and the urge is to say "can it," like the failed AAS that was finally canned in 1994. At about $2 billion (2010 dollars) ERAM has eaten up a lot less than AAS did, at $3.7 billion (1994 dollars). That would be a tough call for users, who really need improvements to a creaky system designed nearly 40 years ago. One thing users might help with is an absolute cap on new requirements. Requirements on this project should have been frozen 6-7 years ago, but apparently they are still changing. Freezing requirements is what makes it possible for a project to work. Requirements creep, as architects call it, undermines a project, raising the cost and vastly increasing the likelihood of collapse. You can't expect Lockheed to fight requirements creep; they make profit on it. They should never have gotten the contract. AAS was built by IBM Federal Systems. By early 1990s FedSys was a money loser, and IBM threw in the towel, selling to Loral, who sold to Lockheed. The same organization that failed at AAS is now building ERAM. It’s easy for system architects to see signs of a sick project in ERAM, and the urge is to say “can it,” like the failed AAS that was finally canned in 1994. At about $2 billion (2010 dollars) ERAM has eaten up a lot less than AAS did, at $3.7 billion (1994 dollars).

That would be a tough call for users, who really need improvements to a creaky system designed nearly 40 years ago. One thing users might help with is an absolute cap on new requirements. Requirements on this project should have been frozen 6-7 years ago, but apparently they are still changing.

Freezing requirements is what makes it possible for a project to work. Requirements creep, as architects call it, undermines a project, raising the cost and vastly increasing the likelihood of collapse.

You can’t expect Lockheed to fight requirements creep; they make profit on it. They should never have gotten the contract. AAS was built by IBM Federal Systems. By early 1990s FedSys was a money loser, and IBM threw in the towel, selling to Loral, who sold to Lockheed. The same organization that failed at AAS is now building ERAM.

]]> Comment on Ignoring the Rules by George http://atcfreqs.com/wpblog/?p=3685&cpage=1#comment-564 George Sun, 27 Jun 2010 02:11:44 +0000 http://atcfreqs.com/wpblog/?p=3685#comment-564 The MAP program is a later version of the 1980"s EnRoute Load Program AKA ELOD. Problem was MAP like ELOD uses a static route not the filed one. So if you are flying from say BOS to LAX MAP puts everyone on the same route. There was suppose to be some route conversion logic put into MAP but the contractor screwed that up. So basically ETMS has no clue what load a sector has at anyone point in time. We had a basic version of MAP running that used boundary crossing messages and TZ updates to at least attempt to provide somewhat accurate numbers. But since we the FAA wrote the code and it conflicted with the MAP program (Washington)we got investigated for misuse of funds. Even though our charter was to develop and improve EnRoute software. We're not allowed anymore because it doesn't generate a performance kickback err, bonus to FAA Washington. When tracks go FREE from FLAT you guys should be getting double time! Good write up and job well done! Cheer up next summer you'll be using ERAM without the HOST tools developed over the last 30 year! The MAP program is a later version of the 1980″s EnRoute Load Program AKA ELOD. Problem was MAP like ELOD uses a static route not the filed one. So if you are flying from say BOS to LAX MAP puts everyone on the same route. There was suppose to be some route conversion logic put into MAP but the contractor screwed that up. So basically ETMS has no clue what load a sector has at anyone point in time.

We had a basic version of MAP running that used boundary crossing messages and TZ updates to at least attempt to provide somewhat accurate numbers. But since we the FAA wrote the code and it conflicted with the MAP program (Washington)we got investigated for misuse of funds. Even though our charter was to develop and improve EnRoute software. We’re not allowed anymore because it doesn’t generate a performance kickback err, bonus to FAA Washington.

When tracks go FREE from FLAT you guys should be getting double time! Good write up and job well done! Cheer up next summer you’ll be using ERAM without the HOST tools developed over the last 30 year!

]]> Comment on ERAM Under the Radar by Sid http://atcfreqs.com/wpblog/?p=3611&cpage=1#comment-563 Sid Wed, 16 Jun 2010 14:56:33 +0000 http://atcfreqs.com/wpblog/?p=3611#comment-563 Thanks for the update and excellent analysis of the current state of ERAM. We have heard nothing at my site. Thanks for the update and excellent analysis of the current state of ERAM. We have heard nothing at my site.

]]> Comment on ERAM Problems No Longer a Secret by George http://atcfreqs.com/wpblog/?p=3585&cpage=1#comment-562 George Mon, 03 May 2010 19:47:19 +0000 http://atcfreqs.com/wpblog/?p=3585#comment-562 Please keep up the good work, you write very well and aren’t a “bomb thrower” but simply provide the facts without the rhetoric. Even we in EnRoute have a difficult time finding out what is really going on with ERAM. Your skilled writing from the controllers prospective is very much appreciated and helps us sift the truth from the propaganda. Please keep up the good work, you write very well and aren’t a “bomb thrower” but simply provide the facts without the rhetoric. Even we in EnRoute have a difficult time finding out what is really going on with ERAM. Your skilled writing from the controllers prospective is very much appreciated and helps us sift the truth from the propaganda.

]]> Comment on ERAM Problems No Longer a Secret by Retired and not flying http://atcfreqs.com/wpblog/?p=3585&cpage=1#comment-561 Retired and not flying Sun, 25 Apr 2010 00:40:46 +0000 http://atcfreqs.com/wpblog/?p=3585#comment-561 Keep up the good work. It must feel pretty lonely being one of the very few writing about ERAM failings. When is NATCA going to start acting like they are concerned with the safety of the flying public? You should be writing about NATCA press releases and studies (oh, that's right, there are none), not DOT IG reports. How long can he FAA hide this fiasco? Keep up the good work. It must feel pretty lonely being one of the very few writing about ERAM failings. When is NATCA going to start acting like they are concerned with the safety of the flying public? You should be writing about NATCA press releases and studies (oh, that’s right, there are none), not DOT IG reports. How long can he FAA hide this fiasco?

]]> Comment on We Apologize for the Delay (in ERAM)… by George http://atcfreqs.com/wpblog/?p=3563&cpage=1#comment-558 George Thu, 22 Apr 2010 15:57:47 +0000 http://atcfreqs.com/wpblog/?p=3563#comment-558 Sadly, I would say your analysis is right on the money. In order to fix the major problems we were experiencing in tracking and Flight Data Management (FDM) would require at least at 6-month slippage or more. Management is talking about, at most 6-weeks in hopes Lockheed can throw enough code at the wall that some of it may stick and actually fix a problem or two. The problems in tracking and track predication appear to be major ones or worse if they are fundamental to the design of the system. Instead of trying to patch an already flawed system Lockheed needs to take a step back in address the problems at their root cause(s). Will they? no, result, unfortunately more of the same. The danger is this time Congress is paying attention and asking questions. Want the FAA budget to get dramatically slashed? Just keep doing what you are doing on ERAM. Sadly, I would say your analysis is right on the money. In order to fix the major problems we were experiencing in tracking and Flight Data Management (FDM) would require at least at 6-month slippage or more. Management is talking about, at most 6-weeks in hopes Lockheed can throw enough code at the wall that some of it may stick and actually fix a problem or two.

The problems in tracking and track predication appear to be major ones or worse if they are fundamental to the design of the system. Instead of trying to patch an already flawed system Lockheed needs to take a step back in address the problems at their root cause(s).

Will they? no, result, unfortunately more of the same. The danger is this time Congress is paying attention and asking questions. Want the FAA budget to get dramatically slashed? Just keep doing what you are doing on ERAM.

]]>