The jet in question was built in the 1980's.
"Numerous altitude changes"?? Our Mode C shows FL600 the entire time, i.e. the computer never sees an altitude change.

 

Thank you Huggy.

I was waiting for your response and knew about your Mode C transmission at FL600.

I guess the question is: Why did the ERAM software at ZLA’s ARTCC overload by “supposedly” tagging the U-2 at 10,000 ft and then trying to re-plot a safe route through the numerous ATC targets over SoCal? This triggered all the events in question.

Considering the U-2 has made many flights over this same area in the past, could it be a flaw has come to light in Lockheed’s golden ERAM software?

 

IMO this is obviously a fault in the center software. Even if an airplane system did malfunction and send too much data, software is supposed to have built in "exception handling" for any reasonably conceivable error.

The most basic example of such an error is an attempt to divide anything by zero, which would crash the processor if not diverted.

A data overload (possibly an intentional Denial of Service attack) should be an obvious exception to plan for.

Even if the U2 malfunctioned, it shouldn't have shut down an ARTCC.

 

Well now there is speculation that it wasn't a U2 (perhaps Russian plane?) because the USAF is now denying there was a U2 there.

 

I asked a friend at ZLA what he knew, and he said nothing went down, they were just getting a lot of error messages and as a precaution they decided to issue ground stops until they could figure it out. There were two technical problems but they were apparently properly handled by ERAM. One was a cut fiber optic line in SoCal that was interfering with flight data transfer to some other facilities (adding to controller workload because some things like handoffs had to be done over the landline).

The second wasn't from a U2, just its flight plan which possibly as a result of the data transfer problem apparently had an altitude of "0" for the flight plan altitude. The long-term conflict probe (EDST) was then checking every few moments for everything from its current FL600 mode C down to the 0 assigned altitude along its winding flight path, checking against probably several hundred VFR and IFR targets in SoCal all going in different directions. This stretched the limit of the CPU or some part of memory and spewed out warning messages, although didn't cause a crash. All those messages on top of the known data transfer failures spooked ZLA enough to decide to ground stop. If there was only one problem or the other, or ERAM wasn't so new, they probably wouldn't have reacted like that. It was just a precaution apparently.

 

or a WB57F. The Aviationist » WB-57F