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

141–150 of 311 posts

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

#141

Post by [deleted] »

skissane wrote: post #131
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…

> 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…

[deleted]

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

#142

Post by MBCook »

mannykannot wrote: post #137
aftbit wrote: post #81

Earlier quoted context omitted.

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 -…

I think you’re on the right track, I assume it’s safety.

If one bad flight plan came in, what are the chances other unnoticed errors may be getting through?

Given the huge danger involved with being wrong shutting down with a “stuff doesn’t add up, no confidence in safe operation” error may be the best approach.

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

#143

Post by gbear605 »

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.

There have been a couple times in the past where I’ve run into an issue marked as WONT FIX and then resolved it on my end (because it was luckily an open source project). If the ticket were still open, it would have been trivial to put up a fix, but instead it was a lot more annoying (and in one of the cases, I just didn’t bother). Sure, maybe the issue is so low priority that it wouldn’t even be worth reviewing a fix, and this doesn’t apply for closed source projects, but otherwise you’re just losing out on other people doing free fixes for you.

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

#145

Post by ryandrake »

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.

I've seen both types of organizations:

1. The bug tracker is there to document and prioritize the list of bugs that we know about, whether or not they will ever be fixed. In this world, if it's a real issue, it's tracked and kept while it exists in the software, even though it might be trivial, difficult, or just not worth fixing. There's no such thing as closing the bug as "Won't Fix" or "Too Old". Further, there's no expectation that any particular bug is being worked on or will ever be fixed. Teams might run through the bug list periodically to close issues that no longer reproduce.

2. The bug tracker tracks engineering load: the working set of bugs that are worthy of being fixed and have a chance to be fixed. Just because the issue is real, doesn't mean it's going to be fixed. So file the bug, but it may be closed if it is not going to be worked on. It also may be closed if it gets old and it's obvious it will never get worked on. In this model, every bug in the tracker is expected to be resolved at some point. Teams will run through the bug list periodically to close issues that we've lived with for a long time and just won't be fixed ever.

I think both are valid, but as a software organization, you need to agree on which model you're using.

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

#146

Post by abstractbeliefs »

J05ephu5M13r wrote: post #144

It's like déjà vu all over again, Yogi. Aug 2023: “UK air traffic woes caused by 'invalid flight plan data'” https://www.theregister.com/2023/08/30/uk_air_traffic_woes_i... -- (-11 down votes and counting)

The very first line of the article states that this is a retrospective of the August '23 incident, hence the downvotes.

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

#147

Post by jp57 »

lostlogin wrote: post #73
andyjohnson0 wrote: post #67

Earlier quoted context omitted.

Even though I knew this was about aviation, I still read nm as nanometres. Now I'm wondering what this says about how my brain works.

It says ‘metric’. Good.

Though one could argue that the (original) definition of a meter and the definition of a nautical mile are equally arbitrary and yet similarly based.

Originally 1 meter was one ten-millionth of the distance over the surface of the earth from the equator to the pole.

One nautical mile is the length one arc-minute of latitude along a meridian. (About 1.85km).

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

#148

Post by jfactorial »

mithametacs wrote: post #139
Arainach wrote: post #89

Earlier quoted context omitted.

>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

> Everything is finite including bugs.

Everything dies including (probably) the universe, and shortly before that, our software. So you're right, the number of bugs in a specific application is ultimately finite. But most of even the oldest software still in use is still getting regular revisions, and if app code is still being written, it's safe to assume bugs are still being created by the fallible minds that conceived it. So practically speaking, for an application still in-development, the number of bugs, number of features, number of lines of code, etc. are dynamic, not finite, and mostly ever-increasing.

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

#149

Post by [deleted] »

MBCook wrote: post #142
mannykannot wrote: post #137

Earlier quoted context omitted.

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 -…

I think you’re on the right track, I assume it’s safety. If one bad flight plan came in, what are the chances other unnoticed errors may be getting through? Given the huge danger involved with being wrong shutting down with a “stuff doesn’t add up, no confidence in safe operation” error may be the best approach.

[deleted]

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

#150

Post by skykooler »

andyjohnson0 wrote: post #67
jp57 wrote: post #9

FYI: nm = nautical miles, not nanometers.

Even though I knew this was about aviation, I still read nm as nanometres. Now I'm wondering what this says about how my brain works.

"Hacker News failure caused by two units 12 orders of magnitude apart sharing 2-letter code"
Post reply on HN