Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

flightglobal.com

Post reply on HN
Print view View original

131–140 of 311 posts

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#131

Post by skissane »

throw0101a wrote: post #82
CrimsonCape wrote: post #65

Earlier quoted context omitted.

C dev: "You are telling me that the three digit codes are not globally unique??? And now we have to add more bits to the struct?? That's going to kill our perfectly optimized bit layout in memory! F***! This whole app is going to sh**"

> C dev: "You are telling me that the three digit codes are not globally unique??? They are understood not to be. They are generally known to be regionally unique. The "DVL" code is unique with-in FAA/Transport Canada control, and the "DVL" is unique with-in EASA space. There are pre-defined three-letter codes: * https://en.wikipedia.org/wiki/IATA_airport_code And pre-defined four-letter codes: * https://en.wikipedia…

> They are understood not to be. They are generally known to be regionally unique.

Then why aren’t they namespaced? Attach to each code its issuing authority, so it is obvious to the code that DVL@FAA and DVL@EASA are two different things?

Maybe for backward compatibility/ human factors reasons, the code needs to be displayed without the namespace to pilots and air traffic controllers, but it should be a field in the data formats.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#132

Post by skissane »

marcosdumay wrote: post #95
throw0101a wrote: post #82

Earlier quoted context omitted.

> C dev: "You are telling me that the three digit codes are not globally unique??? They are understood not to be. They are generally known to be regionally unique. The "DVL" code is unique with-in FAA/Transport Canada control, and the "DVL" is unique with-in EASA space. There are pre-defined three-letter codes: * https://en.wikipedia.org/wiki/IATA_airport_code And pre-defined four-letter codes: * https://en.wikipedia…

Hum... Somebody has a list of foreign local-codes sharing the same space as the local ones? I assumed IATA messed up, not I'm wondering how that even happens. It's not even easy to discover the local codes of remote aviation authorities.

> I assumed IATA messed up,

This isn’t IATA. IATA manages codes used for passenger and cargo bookings, which are distinct from the codes used by pilots and air traffic control we are talking about here-ultimately overseen by ICAO. These codes include a lot of stuff which is irrelevant to passengers/freight, such as navigation waypoints, military airbases (which normally would never accept a civilian flight, but still could be used for an emergency landing-plus civilian and military ATC coordinate with each other to avoid conflicts)

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#133

Post by atonse »

cduzz wrote: post #129
jp57 wrote: post #9

FYI: nm = nautical miles, not nanometers.

I was wondering; it seemed like if the to airports were 36000 angstroms apart (3600 nanometers), it'd be reasonable to give them the same airport code since they'd be pretty much on top of each other. I've also seen "DANGER!! 12000000 μVolts!!!" on tiny little model railroad signs.

That's so adorable (for model railroads)

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#134

Post by outworlder »

wyldfire wrote: post #43
FateOfNations wrote: post #3

Good news: the system successfully detected an error and didn't send bad data to air traffic controllers. Bad News: the system can't recover from an error in an individual flight plan, bringing the whole system down with it (along with the backup system since it was running the same code).

> he system can't recover from an error in an individual flight plan, bringing the whole system down with it From the system's POV maybe this is the right way to resolve the problem. Could masking the failure by obscuring this flight's waypoint problem have resulted in a potentially conflicting flight not being tracked among other flights? If so, maybe it's truly urgent enough to bring down the system and force the h…

> From the system's POV maybe this is the right way to resolve the problem. Could masking the failure by obscuring this flight's waypoint problem have resulted in a potentially conflicting flight not being tracked among other flights? If so, maybe it's truly urgent enough to bring down the system and force the humans to resolve the discrepancy.

Flagging the error is absolutely the right way to go. It should have rejected the flight plan, however. There could be issues if the flight was allowed to proceed and you now have an aircraft you didn't expect showing up.

Crashing is not the way to handle it.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#136

Post by GnarfGnarf »

Funny airport call letters story: I once headed to Salt Lake City, UT (SLC) for a conference. My luggage was processed by a dyslexic baggage handler, who sent it to... SCL (Santiago, Chile).

I was three days in my jeans at business meetings. My bag came back through Lima, Peru and Houston. My bag was having more fun than me.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#137

Post by mannykannot »

aftbit wrote: post #81
wyldfire wrote: post #43

Earlier quoted context omitted.

> he system can't recover from an error in an individual flight plan, bringing the whole system down with it From the system's POV maybe this is the right way to resolve the problem. Could masking the failure by obscuring this flight's waypoint problem have resulted in a potentially conflicting flight not being tracked among other flights? If so, maybe it's truly urgent enough to bring down the system and force the h…

It seems fundamentally unreasonable for the flight processing system to entirely shut itself down just because it detected that one flight plan had corrupt data. Some degree of robustness should be expected from this system IMO.

It does not seem reasonable when you put it like that, but when could it be said with confidence that it only affected just one flight plan? I get the impression that it is only in hindsight that this could be seen to be so. On the face of it, this was just an ordinary transatlantic flight like thousands of others, with no reason to think there was anything unusual about it to make it more vulnerable than the rest - and really, there was not, it just had an unlucky combination of parameters.

In general, the point where a problem first becomes apparent is not a guideline to its scope.

Air traffic control is inherently a coordination problem dependent on common data, rules and procedures, which would seem to limit the degree to which subsystems can be siloed. Multiple implementations would not have helped in this case, either.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#138

Post by exe34 »

Arainach wrote: post #120
Shorel wrote: post #108

Earlier quoted context omitted.

I'm in total disagreement with your last paragraph. In fact, I can't see how it follows from the rest. Software can have defects, true. There are finite resources, true. So keep the tickets open. Eventually someone will fix them. Closing something for spurious psychological reasons seems detrimental to actual engineering and it doesn't actually avoid any real problem. Let me repeat that: ignoring a problem doesn't ma…

It's not "spurious psychological reasons". It is being honest that issues will never, ever meet the bar to be fixed. Pretending otherwise by leaving them open and ranking them in the backlog is a waste of time and attention.

it's more fun/creative/CV-worthy to write new shiny features than to fix old problems.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#139

Post by mithametacs »

Arainach wrote: post #89
telgareith wrote: post #69

Earlier quoted context omitted.

Dig into the OpenZFS 2.2.0 data loss bug story. There was at least one ticket (in FreeBSD) where it cropped up almost a year prior and got labeled "look into layer," but it got closed. I'm aware closing tickets of "future investigation" tasks when it seems to not be an issue any longer is common. But, it shouldnt be.

>it shouldnt be Software can (maybe) be perfect, or it can be relevant to a large user base. It cannot be both. With an enormous budget and a strictly controlled scope (spacecraft) it may be possible to achieve defect-free software. In most cases it is not. There are always finite resources, and almost always more ideas than it takes time to implement. If you are trying to make money, is it worth chasing down issues…

Everything is finite including bugs. They aren’t magic or spooky.

If you are superstitious about bugs, it’s time to triage. Absolutely full turn disagreement with your directions

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#140

Post by mithametacs »

crtified wrote: post #115
jrochkind1 wrote: post #33

I don't know how long that failure mode has been in place or if this is relevant, but it makes me think of analogous times I've encountered similar: When automated systems are first put in place, for something high risk, "just shut down if you see something that may be an error" is a totally reasonable plan. After all, literally yesterday they were all functioning without the automated system, if it doesn't seem to b…

Also, as codebases and systems get more (not less) complex over time, the potential for technical debt multiplies. There are more processing and outcome vectors, more (and different) branching paths. New logic maps. Every day/month/year/decade is a new operating environment.

I don’t think it is exponential. In fact, one of the things that surprises me about software engineering is that it’s possible at all.

Bugs seem to scale log-linearly with code complexity. If it’s exponential you’re doing it wrong.

Post reply on HN