Huge Design Flaw Discovered in ERAM
Posted by Paul Cox on May 29th, 2009
Here’s a Follies exclusive…
The new system known as ERAM (EnRoute Automation Modernization), one of the most expensive and complex systems the FAA has ever undertaken, has a major design flaw that could set the already-delayed upgrade program back months.
The problem was discovered by Seattle Center’s ERAM team. It involves the tracking of aircraft targets. ERAM is designed to be the brain and backbone of the nation’s air traffic control system; nearly every commercial flight within the United States would run under the software.
ERAM is the main operating system and application at the nation’s 20 enroute air traffic control centers. It integrates radar data, flight plans, weather, and a myriad of other information to produce all the information onto controllers’ scopes so they can provide ATC services. Additionally, it will handle all the flight data processing for any aircraft that are entering or leaving one of the nation’s several hundred TRACONs. As such, ERAM is slated to be absolutely critical in the FAA’s plans for modernization of the ATC system with “NextGen”, the satellite-based upgrade intended to greatly increase capacity.
When the ERAM testing team finds a bug or problem with the software, they generate a “PR”, or problem report. PRs are rated by their seriousness; a PR in the A1 category is of the utmost importance and the analogy used to describe it is “if there’s an earthquake, an A1 problem would mean the building collapses completely.” An A2 is extremely serious; an A3 PR would be bad enough to cause “operational errors”, events when controlled aircraft get too close together and run a higher risk of colliding.
The tracking problem is rated as an A2 PR, so it is very serious.
Aircraft are “tracked” by the present HOST software based on where the radar “sees” the aircraft’s transponder. The tracking function is extremely important because the airplane’s data tab on the controller’s scope accompanies the radar target, telling the controller who the target is, the altitude, its speed over the ground, and other crucial data.
The ERAM system’s tracking functions apparently change the basic paradigm. Instead of the tracking function basing the track on the radar target, the tracking subroutine is said to be based on the flight plan data and is unable to keep tracking an aircraft if it is doing something other than what the flight plan indicates.
For example, if an aircraft is filed to depart an airport and fly due south along the filed route of flight, that is where ERAM tries to track the plane. If the runway in use dictates that the aircraft departs in a northerly heading, and the plane doesn’t turn south but instead has to continue north for a few miles (a common occurance due to traffic, terrain, noise, and other considerations) then the track is lost and the data won’t stay on the actual radar target.
This flaw goes right to the very heart of the design of the software. It is as yet unknown how serious this will be in terms of getting ERAM out on time, but the odds are that the flaw will set the program back significantly as the field facilities will almost certainly refuse to implement ERAM until it’s been repaired and works properly.
ERAM’s initial operating capability (IOC) date at Seattle Center has already slid from a date of late 2008 (at one point) to the second half of 2009. No word yet on if, or how long, this latest flaw will push the program into the future.
May 29th, 2009 at 3:12 am
Amazing, eh?
And the FAA already paid the contractor millions and millions of dollars for this, right?
May 29th, 2009 at 3:34 am
Paul,
Always enjoy your posts and observations! Controllers demand and deserve a quality system and there are lots of folks in the trenches working for that; those very same people will be the first to point out problems in the system too. Much of this post is 100% wrong. And another large portion is only barely accurate. With all due respect to the ZSE team they have not “discovered” a (newsflash) major design flaw. I have come to expect well researched and eloquent presentation of facts on the Follies, but you sometimes miss the mark on the technical aspects of ERAM. The ZSE team are a bunch of hard working folks, please don’t embarass them with half-truths or inaccurate facts.
And as always, keep up the great work too!!
May 29th, 2009 at 5:02 am
If ERAM and NEXTGEN actually happen, how are we supposed to get information on an airplanes position? Is it by their transponder? If there is no primary radar, is it possible to electronically fool us on your position? If it is, I expect Cheney will spend the rest of his life hiding in a bunker under a house in some unknown location.
May 29th, 2009 at 5:55 am
Jamjets, you sound like a credible source, who are you? If Paul is wrong let us know!
May 29th, 2009 at 6:15 am
Jamjets….please fill us in on the real truth on ERAM then. You certainly sound like you have information that would be useful to a facility that is looking down the barrel of ERAM….and sooner or later the FAA is going to pull the trigger, regardless of if it’s ready or not.
May 29th, 2009 at 6:58 am
Although jamjets sounds credible he issues only denials without providing any real information on how Paul is mistaken.
Unless he can back this up with credible facts including copies of reports (like Paul has)he is just another Lockheed Martin PR flack cruising the internet trying to spin their latest failure.
Hey LM, hows that FSS new software working out for you?
Still unusable with out major workarounds what 4 years later?
May 29th, 2009 at 7:54 am
Jamjets,
I challenge you to reveal your true identity and prove Paul wrong with appropriate, credible documentation.
May 29th, 2009 at 8:10 am
As a pilot who uses the ATC system almost daily, this is interesting… not surprising, but interesting.
May 29th, 2009 at 9:15 am
GREAT post. Paul.
I expect to see you post this and more information on NATCA’s BBS so we can discuss it further…..
Oh wait, THAT won’t happen because you’ve been labeled a ‘troublemaker’ and banned for life from the NATCA BBS. (sigh)
Don’t like the message? Shoot the messenger!
May 29th, 2009 at 9:25 am
My info came from ERAM test team members. If it’s wrong I’ll definitely print a retraction.
What I wrote is a reflection of how the problem has appeared to them in terms of the tracking issues, and also how the cause of the problem has been explained to them.
The fact that ERAM has slid, and slid, and slid is real. Back in March, the FAA’s PR people had articles running in publications like “Aviation Week” about how ERAM was about to go IOC at Seattle Center and Salt Lake Center, and yet we have still not gone IOC and are not scheduled to do so until a July-August time frame.
The article might be wrong… but if so, then what the test team members are telling me is wrong and the information that’s been given to THEM is wrong as well.
My contact info is faafollies@gmail.com and I stand ready to discuss ERAM with anyone knowledgeable who can clarify things.
May 29th, 2009 at 9:30 am
Jamjets,
Perhaps Paul was giving one side of the story in the hope of eliciting someone more ‘in the know’ to give everyone the real story. LOOKIN AT YOU BUD
May 29th, 2009 at 10:31 am
jamjet=driveby. Just like I figured. Good article Paul.
May 29th, 2009 at 11:04 am
The info in question isn’t “wrong” per se, it just isn’t new. This issue was discovered months ago when it was found that Eram does not interrogate the target. The issue in question at ZSE appears to be a subset of this problem.
May 29th, 2009 at 11:19 am
If the issue was known and it is an issue that someone familiar with the nitty gritty of air traffic control would find unacceptable to a deployed system then I am wondering how it got to the stage where it was being tested at ZSE without that bug being fixed. Was it a bug that the contractor had already slated for a regression build, and that regression build was going to be completed by the time the system was officially deployed to ZSE? That’s unorthodox but at least it would make some twisted kind of sense.
Another scenario is that the contractor not realize the full significance of the bug with regards to air traffic control but I would hope this is not the case.
May 29th, 2009 at 11:24 am
So JamJet – As a controller at ZSE, I was told the same things by our testers. Do you just have an issue with the way Paul described the problem? Maybe you didn’t like the idea that our guys ‘discovered’ something, or maybe you don’t think (for whatever reason) that it’s a ‘major design flaw’ ?
The bottom line is that an A2 was generated, and you don’t seem to think it’s an issue. I think you should let the CONTROLLERS decide what the problems are and aren’t, since we’re the users and subject amtter experts.
I don’t care about your secret identity, but if you have some infortmation that would help alleviate this misguided concern (that generated an A2 PR, btw) please share it with the rest of us. Otherwise get out of the way — you think we’re a bunch of Rubes ?
May 29th, 2009 at 12:30 pm
Hello? Calling Jamjets?
Hell I trust Paul and many others before I would even begin to trust ONE WORD out of any non-controller from the FAA. Trust the gel man led spinning vortex that is the FAA? HAH! The fact that you, jamjets, after a drive-by shut your mouth after you were called out speaks wonders for both Paul and NATCA.
I know who I trust, and it is NO-ONE in FAA management.
May 29th, 2009 at 12:44 pm
Ingridbackstromsboyfriend Said:
“This issue was discovered months ago when it was found that Eram does not interrogate the target.”
ERAM does NOT interrogate ANY targets. Neither does Host, ARTS, nor STARS. Interrogation is not a function of the automation systems, but is a function of secondary radar (beacon). The automation systems take data from the radar systems (both secondary and primary), process the data, and supply information as targets and tracks to ATC.
May 29th, 2009 at 12:58 pm
What I find interesting is that Lockheed Martin “owns” the tracking algorythms used by HOST.
So I’m wondering why ERAM is having problems with a Lockheed Martin tracker? What are they trying to do that is causing them problems? Why is the tracker so dependant upon flight plans rather than the actual radar returns? Does the ERAM tracker use primary tracking, or only secondary? How will ERAM track when using ADS-B (GPS) data rather than radar? Will it still be dependant of flight plans? Does this restrict deviations by the aircraft? Questions, question, questions.
Back when I was working on STARS developement and deployment, we were having problems with the tracker that Raytheon had developed. At one point, STARS was going to use the Lockheed Martin tracker because it had already been in use in U.S. ATC, and was a proven tracker for what we were trying to accomplish. Eventually, Raytheon was able to keep their tracker even though, IMHO, it was an inferior tracker.
.
May 29th, 2009 at 1:00 pm
If you want to learn all there is about ATC Radars, check out this web site:
http://www.radartutorial.eu/index.en.html
.
May 29th, 2009 at 1:11 pm
I wouldn’t jump all over Jamjet for not replying, considering that he wrote his post at 3:34 AM this morning. If he has not replied within 24 hours then sure, talk a little smack, but at least give the man a little time to sleep/work/whatever before jumping all over him for not being glued to his computer.
May 29th, 2009 at 2:03 pm
AHHH, another fine Lockheed Martin product!!!! We’re all anticipating the replacement for FS21, Yes, Phil “All I Can Say Is Wow” Boyer, the wondercrap you endorsed as amazing is already being replaced. If LM’s track record is any indication, it will probably be a piece of crap!!!
May 29th, 2009 at 2:56 pm
Everyone… if “jamjets” is who I think it is, then he’s a reliable source who is in a position to educate and inform us on these issues. I’ll wait to hear from him personally to see what information he’s got and see if we can clear the story up some.
May 29th, 2009 at 3:43 pm
Now now now…. let’s leave Jamjet alone.
We look forward to delivery of the new program in spring… er… summer…. er… fall. Working as designed and without “workarounds”. Thank you for setting the record straight Jamjet!
Won’t track aircraft, eh? Yeah, that sound like a small problem.
“On track and under budget”
May 29th, 2009 at 7:36 pm
Dale
Yes I know Eram doesn’t look at targets I used the wrong words to describe the issue. Have you ever used the wrong words? I think based on your response that you get what I am talking about.
My point was more along the lines of this is an old issue and what the zse dudes figured out is a small subset of the bigger issue. In other words its news but not something new. IT AINT A SCOOP. In fact the new version coming out on Tuesday????? has a supposed fix for this issue.
May 29th, 2009 at 7:40 pm
PS
This thread has all the makings of just another koolaid fest. The pitbulls jumping to Pauls defense and calling out jamjets are no better off than the higher skill set.
May 29th, 2009 at 8:56 pm
shouldn’t a critical atc system be proven for at least 3 mo. without changes before going live?? who knows, i’m just an idjit, not capable of doing atc automation…
May 29th, 2009 at 8:57 pm
IngridBackstromsboyfriend,
I’m sorry, but if you are going to try to talk about technical issues, then you must use appropriate language for that issue.
Even in your later post, you said “…I know Eram doesn’t look at targets…”, and you used inappropriate language again. If you really looked at my post, you would see that ERAM does “look” at targets. In fact, that is one of it’s most important jobs. It just does not initiate a transponder query (interrogation).
So, please, double check what you are writing and make sure it expresses what you want to say. Anything less makes you look like a fool trying to impress people with your misconception of the technology.
You are right however that this issue is a subset of a larger issue. The issue is that this software has never been tested as one integrated package before, and nobody can predict how it will respond to any give change. The final result will be to minimise issues, not eliminate them. The day that STARS went IOC, there were over 400 known issues. But those issues were deemed minor in nature and IOC occurred despite protests from the local controllers. And STARS had over 4 years of testing an integrated software package.
How do you think ERAM will fare with it’s lack of integrated testing?
.
May 30th, 2009 at 3:28 am
From another website,
As of yesterday, I was told by members of our testing team that they identified an issue just as xxxx described on the xxxxxxx.
Whether or not that xxxxxxxx guy has anything credible, I don’t know. But I DO know that ERAM continues to have issues with tracking beacon targets.
:
Much of this post is 100% wrong. And another large portion is only barely accurate. With all due respect to the ZSE team they have not “discovered” a (newsflash) major design flaw. I have come to expect well researched and eloquent presentation of facts on the Follies, but you sometimes miss the mark on the technical aspects of ERAM. The ZSE team are a bunch of hard working folks, please don’t embarass them with half-truths or inaccurate facts.
It’s possible that xxxxxxx is being picky on the way xxxx described things – maybe he has issues with “ZSE team ‘discovering’ the major design flaw” — maybe xxxxxxx knows something about how this problem works and it’s not a ‘major design flaw’ (although to us controllers using it, it’s a major issue!).
Or maybe xxxxxxx is a LockheedMartin guy just trying to protect his product.
But I do know this – that tracking issue did happen as described by Paul, and there has been an A2 problem report generated on it, which would need to be fixed before IOC.
Another thing – our testing cadre has mentioned that there are issues that exist in the ERAM program that LockMart knows about, but it’s up to us to identify the issues for them to fix – they do not volunteer anything! If there’s something wrong with the way it works, it’s up to our guys to identify them as such, otherwise LM assumes it’s good.
Safety Above All ! (unless there are bonuses related to milestones, and political pressures exceed NATCA’s ability to demand a safe and usable product!)
May 30th, 2009 at 3:30 am
In fact the new version coming out on Tuesday?????
I will gladly pay you Tuesday, for a hamburger today.
(Wimpy).
May 30th, 2009 at 6:02 am
I think it is an incredible testament to the IBM programmers who developed the original NAS RDP and FDP software in the 70′s. With the software tools they had available in those days, they wrote the core NAS program that still runs in 16 megs of memory (a huge amount back then) and has done so for 30+ years.
May 30th, 2009 at 6:12 am
“I think it is an incredible testament to the IBM programmers who developed the original NAS RDP and FDP software in the 70’s. With the software tools they had available in those days, they wrote the core NAS program that still runs in 16 megs of memory (a huge amount back then) and has done so for 30+ years.”
They made up for this with their contract to make the sector suites.
May 30th, 2009 at 9:10 am
“Back when I was working on STARS developement and deployment, we were having problems with the tracker that Raytheon had developed. At one point, STARS was going to use the Lockheed Martin tracker because it had already been in use in U.S. ATC, and was a proven tracker for what we were trying to accomplish. Eventually, Raytheon was able to keep their tracker even though, IMHO, it was an inferior tracker.”
It’s actually worse than that, Dale. Raytheon builds ASR-11 with no tracker (unlike ASR-9 which has an excellent tracker built in) to save money. Raytheon builds STARS with a tracker to compensate for what their ASR-11 product does lacks. At ASR-9 sites, the superior built-in tracker can’t be used with STARS because it interferes with the STARS tracker, so STARS ASR-9 sites have to go with the inferior tracker. Meanwhile, to this day, the STARS tracker is extremely dependent upon all kinds of site-dependent software filtering, filtering which seems to keep getting reverted to previous, non-working filter limits practically each and every time a new build is installed. It drives me NUTS, especially since we in IOT&E identified ALL of these short comings YEARS ago, and the only reason we (the IOT&E team) bought off on deployment was because of empty promises from both the FAA and Raytheon that both the tracker issue and the filter limit relapses would be addressed. Yeah… RIIiiight.
May 30th, 2009 at 10:19 am
LOL
Your right, Doug. We had to turn the ASR-9 tracker off because STARS could not meet throughput (time from reception at the antenna till target display on the scope – approximately 1.2 seconds) specs with it turned on, and there was no easy way to turn the STARS tracker off without going back to the drawing board.
Then, along come ASR-11 (another Raytheon product), and since STARS was going to be THE common automation system, the FAA/Raytheon said they didn’t need a tracker in the ASR-11.
And I agree with you that the ASR-9 tracker is far superior. Especially if you have good clear day maps, and keep them up to date (even better if you have seasonal clear day maps).
Now, another system comes along (ERAM) and the FAA program office is making the same mistakes that it did with the Advanced Automation System (sector suites et al), STARS, and any number of other systems bought by the FAA. Small wonder since the program office is the same people for all these systems. Makes you wonder about their intelligence when they never seem to learn from their mistakes.
May 30th, 2009 at 10:43 am
ZLC discovered this months ago, Works as designed.. Too bad if the design doesn’t work.
May 30th, 2009 at 11:21 am
While there have been numerous issues with tracking identified during ERAM testing, the particular issue described by Paul had not yet been one of them, at least not at ZSE, otherwise it would NOT have generated a NEW A2 PR. Lockheed Martin and the FAA continue to claim most big issues will be fixed “in the next drop”….I wish I had a dollar for every time we have heard that line. There is no way that anyone at either ZLC or ZSE, or having any involvement in ERAM can be optomistic that most of these major issues will be fixed any time soon. The IOC dates continue to slip, while the facilities are being held hostage and the workforce continues to be trained on a system that isn’t working properly. Schedules are jacked up, developmental’s are having their training delayed, OT is assigned then cancelled then re-assigned, etc. The FAA has somehow agreed to try and bring a system online where a vast majority of the testing is being done at the field level.
May 30th, 2009 at 12:48 pm
I was sitting next two the two guys in ZSE when they found this ‘Non-Existant’ flaw. Sure looked preety vaild to me but hey, I’m just a controller – what do I know?
May 30th, 2009 at 3:49 pm
FAA employee falls to his death at Palm Beach International Airport near West Palm Beach
Listen to this article or download audio file.Click-2-Listen
By ANDREW MARRA
Palm Beach Post Staff Writer
Friday, May 29, 2009
A Federal Aviation Administration employee fell to his death today at Palm Beach International Airport while working on a tower, officials said.
The man, whose identity was not released, plummeted while working sometime after 11 a.m., according to Teri Barbera, spokeswoman for the Palm Beach County Sheriff’s Office.
“Somehow he fell to his death,” Barbera said. “It’s not known how he fell.”
FAA spokeswoman Kathleen Bergen said it appeared that the man “fell from the platform of a decommissioned radar antenna.”
The man was a technical operations employee whose job was to install and maintain FAA equipment at the airport.
The sheriff’s office and the FAA are investigating the death. Bergen could not say what he was doing on the antenna at the time.
“We’re looking into every aspect of this incident,” Bergen said.
http://www.palmbeachpost.com/localnews/content/local_news/epaper/2009/05/29/0529faadeath.html?imw=Y
May 30th, 2009 at 3:51 pm
Another example of our employer failing to provide adequate safety for our employees.
The OSHECOMM program is broken.
It does not exist within my “line of business” AVS.
It is crippled in other lines of business, including among technicians. Where is the two-man rule for climbing? Why do employees die in the FAA?
Time for change.
May 30th, 2009 at 4:07 pm
Fall protection was discussed in at least the last two ASO OSHECOMM meetings.
See the minutes of the meetings here:
https://employees.faa.gov/org/regional_offices/aso/safety/OSHECCOM/meeting_minutes/index.cfm
Also note the 5/2008 minutes, who was present, and who was absent. Management was absent. That is the priority they place on OSHECOMM, they don’t even bother making the quarterly meetings. ASO had only two of four required quarterly OSHCOMM meetings.
At the May 2008 meeting, fall protection was discussed. Here is who was absent from that meeting:
Members Absent: Representing Location
Les James TechOps ESA/RO
James Garrett Safety Assurance ESA/RO
Linda Chatman Executive Operations ESA/RO
Susan Northrup ASO-300 Medical Southern Region
Raymond Blue P&R – Requirements ESA/RO
Bruce Gregory En Route Jacksonville ARTCC
Steve Hardee P&R – PIM/Eng. Svc ESA/RO
James Garrett Safety Assurance ESA/RO
Mark Hookings TechOps ESA/ATL TSC
Felix Enriquez Manager, Eastern Service Center ESA/RO
Jaci Malone Office of Civil Rights ESA/RO
Elsie Anglea EnRoute and Oceanic Services Jacksonville ARTCC
These people all must have had something more important to do that day then attend the OSHECOMM meeting.
In the February 2009 meeting, a great deal of time was spent by the Unions trying to explain the importance to MGT of proper fall protection for employees. Guess what? Any decisions were put off until the next meeting- which is June 10th. What to bet they talk about fall protection again then?
Hold management accountable for the death of a fellow employee.
May 31st, 2009 at 7:52 am
A few years the FAA showed a training movie on the space shuttle “O Ring” disaster. ERAM has many problems, but the rush is on implement an unstable system that is nowhere near ready for live ATC. The FAA program managers need to watch that movie, and start thinking about safety and stop thinking about their own careers.
May 31st, 2009 at 3:53 pm
Rangers,
I remember that, but I thought it was a power point presentation. After the explanation, they then tied in several other major disasters with a several word summary of fault. The LAX collision between US Air and the Skywest Metroliner was there with the sensational photo and caption: “Controller Error”. The problem is that was not what the NTSB found. Management Failure would have been more accurate.
And so it continues. I would love to hear more about what I assume is PASS’ arguments for fall protection. But in the meantime, even IF OSHA finds FAA management at fault it will be repackaged by a most prodigious FAA Headquarters PR corps and end up appearing that this poor person threw himself off the tower. Pitiful.
Bob Marks
June 1st, 2009 at 10:38 am
At my ssc, fall protection training was given to anyone who may even think about climbing. The climbing gear was then issued to each ATSS. Making the ATSS wear their protective gear is another issue all together. A few months ago in another Florida town an ATSS was flahsed with electricity causing him to lose a large chunk of skin on his hand. He had electrical safety training, he had electrical safety gloves, but chose not to use them. As a result, management has now warned all employees, if you don’t wear the stuff we give you and train you for, you will be subject to discipline. Even as an old union guy, I can see their point of view.
Don’t be so quick to judge Tech Ops management or the ATSS when we really don’t know the circumstances around the fall.
June 2nd, 2009 at 11:20 am
I hope the training ATSS receive is better than the “training” ATCS get. Much of the FAA’s training for ATCS are boiled down to crappy boring videos and CBIs that really don’t train anyone and are basically a waste of time. They are a “check the box” type item to show that “training” was accomplished so now go out and work bad weather season or icing conditions ect or climb a tower.
Terrible news is that someone died and it probably could have been prevented. Bottom line is the FAA will never admit to any wrong doing and we all know it.
June 4th, 2009 at 7:46 pm
>I think it is an incredible testament to the IBM programmers who developed the original
>NAS RDP and FDP software in the 70’s.
I must say, FAA Guy has a GREAT point here!!! I agree.
June 8th, 2009 at 3:07 pm
Yeah, the very next comment tells the current state of the FAA and the 4 to 5 BILLION dollars wasted only two decades later with no end product.
27+ Wearing Sneakers Says:
May 30th, 2009 at 6:12 am
““I think it is an incredible testament to the IBM programmers who developed the original NAS RDP and FDP software in the 70’s. With the software tools they had available in those days, they wrote the core NAS program that still runs in 16 megs of memory (a huge amount back then) and has done so for 30+ years.”
They made up for this with their contract to make the sector suites.”
June 16th, 2009 at 9:17 am
I think the key point in this discussion is the observation:
Someone gave an unclear explanation of the ERAM tracker to field personnel. The ERAM tracker is based on the Raytheon STARS tracker. It is a “track all” system in that it starts tracks for each unique series of target returns it receives whose apparent velocity is above a threshold (around 100 knots). There is absolutely no dependency on flight data for starting or maintaining tracks. The position and – in the case of secondary returns – beacon codes are all that is used establish tracks.
The process of establishing a relationship between flight plans and the tracks is called association. Beacon codes are the primary key used to make the association. Once a track has been associated with a flight plan, the various fields in the data block can displayed with the target returns on the controllers screen.
The filed route of flight is not used in any way in the ERAM tracking process. However, it was an option for the Host tracker. This was called FLAT (flight plan assisted tracking). FLAT tracking was intended to make the Host tracker more responsive to planned turns. This would be useful because trackers are projecting the target history into the future. If an aircraft was going straight and then starts a turn it takes the tracker (any tracker) some time to adapt to the turn. The adaptation time is called tracker lag. FLAT tracking was included in the Host design to reduce tracker lag at the start of planned turns. Unfortunately, turns rarely occur exactly where the flight plan says they will so the FLAT tracking process was found not to be effective and was disabled in the Host.
The ERAM design does not include FLAT tracking. Instead, it includes two trackers – one assumes that the aircraft is in straight flight and the other assumes that the aircraft is turning. The estimates from the two trackers are weighted based on the difference between the actual position of the most recently received aircraft target and where each tracker predicted that position to be. The filed flight plan is in no way used in this process.
In addition to starting and maintaining tracks, there is special logic to terminate tracks when target data is no longer being received. This can’t be done immediately after missing the first expected target since tracking needs to be maintained for aircraft that briefly fly into areas without RADAR coverage. When the target stream resumes, the tracking can resume without the delay (around 24 seconds) required to start a new track. This is tricky in the airspace around airports. When an aircraft lands, the target stream stops. When some other aircraft departs, a new target stream begins. If the period for retaining a track after the target stream has stopped is been set too high and the beacon code of the arriving aircraft is reassigned to a departing aircraft then the track continues following the wrong aircraft. This isn’t a design error it is a problem in setting the proper value for the track termination timer. This seems to be a reasonable explanation for the problem being observed.
While this is true, ERAM is being compared to a system that has been debugged for 30 years. That raises the question “Why not keep the Host another 30 years?” The reason is that the Host is in every way obsolete. The application is written in a combination of Jovial and IBM/360 assembler language. The number of programmers with these skills is very small. The hardware the Host executes on is so old that extraordinary measures are required to supply replacement parts. The Host is limited to 16 megs of memory because the coding style used in the 1970’s only allocated 24 bits for addressing so it can’t be ported to more modern hardware software changes that are likely to introduce software bugs. In addition, significant software enhancements are needed to support new capabilities such as ADS-B, Data Communications, and SWIM. It’s hard to imagine how these changes could be made using Jovial and IBM assembler. Whether one likes it or not, the Host has a limited life span and ERAM is the only way forward.