U-2 Spy Plane Fries ATC!

Not. These U2s have been flying for decades.:no:
 
If this is true, someone either sucks at making test cases or neglected to test all scenarios before implementing new software.

Of course, I have never done such a thing...
 
As long as the requirements actually said to deal with aircraft at 100k plus altitudes. I'm betting the spec never said one way or the other and some one new wrote code and did not know about the unwritten requirement and so did not code for it. I've seen things like this all to often in long term software projects. back in the day things did not get real good requirement and it works so no one went back to write down the real requirements and it flew under the radar ( so to speak :)) until it got broken. Then lots of screaming from management wanting to know how this could have happen and no one will stand up and say "it's because you rejected all the projects that were designed to go back and retrofit the requirements to match what the software actually did because you did not want to spend the money:
 
No excuse for not paying attention to defensive programming.
 
As long as the requirements actually said to deal with aircraft at 100k plus altitudes. I'm betting the spec never said one way or the other and some one new wrote code and did not know about the unwritten requirement and so did not code for it. I've seen things like this all to often in long term software projects. back in the day things did not get real good requirement and it works so no one went back to write down the real requirements and it flew under the radar ( so to speak :)) until it got broken. Then lots of screaming from management wanting to know how this could have happen and no one will stand up and say "it's because you rejected all the projects that were designed to go back and retrofit the requirements to match what the software actually did because you did not want to spend the money:
According to the article, it was at 60,000.
 
First enroute facility went IOC (Initial Operating Capability) on ERAM in 2012. ZLA just went IOC about three weeks ago.
 
Pure speculation...

Someone updated the software and introduced a bug. Perhaps the aircraft reported an altitude of >65,536'


That was my guess, although I don't know if ATC software would store altitude (say 66000ft) as 66000, which would overflow an unsigned 16bit integer, or if it would store it simply as 660, which isn't particularly close to any computationally-significant boundary I can think of.
 
Having paid attention to the FAA since the early 50's this is just more of the same, ho hum. Nothing to see here folks, move along.
 
That was my guess, although I don't know if ATC software would store altitude (say 66000ft) as 66000, which would overflow an unsigned 16bit integer, or if it would store it simply as 660, which isn't particularly close to any computationally-significant boundary I can think of.

I doubt it would be stored as 660. To store it as 660 you would have to have an additional variable that defined if you mean 660ft or 66000ft. It's simpler just to store the entire value and use programming to display the value truncated. Most modern programming languages can dynamically type the variable though, so this scenario is only likely if they're using something like C++.
 
Having paid attention to the FAA since the early 50's this is just more of the same, ho hum. Nothing to see here folks, move along.


I always get a kick out of folks arguing that incompetence in government is okay because it's always been that way.

It's okay to be apathetic about it, but not so good to argue for it. ;)
 
That was my guess, although I don't know if ATC software would store altitude (say 66000ft) as 66000, which would overflow an unsigned 16bit integer, or if it would store it simply as 660, which isn't particularly close to any computationally-significant boundary I can think of.

All the systems that I'm aware of use 3 digits for altitude and ground speed. Perhaps ERAM is different but the old stuff I used (ARTS IIIA) only indicated 3. Only way I knew airspeed was 3 digits because I watched an F-15 in the warning area going over 1,000 kts at FL490. Shows up as *** on the scope.
 
I always get a kick out of folks arguing that incompetence in government is okay because it's always been that way.

It's okay to be apathetic about it, but not so good to argue for it. ;)

People don't care about apathy.
 
All the systems that I'm aware of use 3 digits for altitude and ground speed. Perhaps ERAM is different but the old stuff I used (ARTS IIIA) only indicated 3. Only way I knew airspeed was 3 digits because I watched an F-15 in the warning area going over 1,000 kts at FL490. Shows up as *** on the scope.


Core RAM was expensive. LOL
 
I was just briefed that the issue had something to do with the use of OTP in the altitude block and ERAM not knowing how to deal with it in this particular situation. We're not supposed to use "OTP" or "VFR" without an altitude with it....VFR/145, etc...
 
I was just briefed that the issue had something to do with the use of OTP in the altitude block and ERAM not knowing how to deal with it in this particular situation. We're not supposed to use "OTP" or "VFR" without an altitude with it....VFR/145, etc...


Boy. Ya gotta love a system that fails gracefully. One field wrong on one target blows it up. Impressive.
 
I know controlled airspace tops out at 60K, but is FL600 a fileable altitude?
 
I know controlled airspace tops out at 60K, but is FL600 a fileable altitude?

Class A tops out at FL600. It's Class E above that. That's controlled airspace, so you can indeed file (at least in principle).

Curiously, the definition of Class E has no top, so you could file on Jupiter if it were above the 48 states….and you could write that many digits in the "altitude" block. I suspect radar contact may be a problem, so you'll have to make position reports.

See 14 CFR 71.71(a).
 
Last edited:
I know controlled airspace tops out at 60K, but is FL600 a fileable altitude?

Controlled airspace does not top out at 60K. The upper limit of Class A airspace is FL600, there's Class E airspace above.

FL600 is not an available altitude. I had an ER-2 request it once, I cleared him to FL610. He cancelled IFR at FL600.
 
Curiously, the definition of Class E has no top, so you could file on Jupiter if it were above the 48 states….and you could write that many digits in the "altitude" block. I suspect radar contact may be a problem, so you'll have to make position reports.

There's no established upper limit to Class E airspace but there are limits to national sovereignty. The Russians set the precedent with Sputnik, they asked no nation for permission to overfly their territory.
 
Class A tops out at FL600. It's Class E above that. That's controlled airspace, so you can indeed file (at least in principle).

Curiously, the definition of Class E has no top, so you could file on Jupiter if it were above the 48 states….and you could write that many digits in the "altitude" block. I suspect radar contact may be a problem, so you'll have to make position reports.

See 14 CFR 71.71(a).

Jupiter sticks to the ecliptic, so is not over anywhere not in the tropics, so only HI can have Jupiter directly overhead at any time.
 
There's no established upper limit to Class E airspace but there are limits to national sovereignty. The Russians set the precedent with Sputnik, they asked no nation for permission to overfly their territory.

I read a paper once that the US could have beaten the Russians on Sputnik, but Eisenhower wanted them to establish the precedent of free overflight in space.
 
From what I understand the altitude bug caused the primary channel to freeze and pass the problem on to the backup channel, which, go figure, froze.

I've heard that the people who created ERAM didn't think a turn more than 30 degrees would ever happen either. Doing so would cause the data block to drop. I don't have anything to back that up other than hearsay though since I'm not a center guy.
 
From what I understand the altitude bug caused the primary channel to freeze and pass the problem on to the backup channel, which, go figure, froze.

I've heard that the people who created ERAM didn't think a turn more than 30 degrees would ever happen either. Doing so would cause the data block to drop. I don't have anything to back that up other than hearsay though since I'm not a center guy.

Yeah, that happened in the first version of ERAM...but thankfully never made it out to IOC with the first facilities. If this is the biggest hiccup ERAM has seen, I'm impressed. Anyone who's read up on the disaster NAS/HOST caused when it first came out would be hard pressed to disagree.
 
Wait until someone enters a negative number for direction like -30 degrees.

Or worse yet, a negative frequency.
 
Back
Top