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

111–120 of 311 posts

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

#111

Post by amelius »

ericjmorey wrote: post #99
ronsor wrote: post #93

Earlier quoted context omitted.

> The general engineering challenge, is how we deal with little-used little-seen functionality (definitely thinking of fault-handling, but there may be other cases) that is totally reasonable when put in place, but has not aged well, and nobody has noticed or realized it, and even if they did it might be hard to convince anyone it's a priority to improve, and the longer you wait the more expensive. The solution to th…

Which company deployed a chaos monkey deamon on their systems? Seemed to improve resiliency when I read about it.

"Your flight has been delayed due to Chaos Monkey."

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

#113

Post by tialaramex »

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.

Indeed. There are plenty of things in aviation where they care so much about compatibility that something survives decades after it should reasonably be obsolete and replaced.

Inches of mercury, magnetic bearings (the magnetic poles move! but they put up with that) and gallons of fuel, all just accepted.

Got a safety-of-life emergency on an ocean liner, oil tanker or whatever? Everywhere in the entire world mandates GMDSS which includes Digital Selective Calling, the boring but complicated problems with radio communication are solved by a machine, you just need to know who you want to talk to (for Mayday calls it's everyone) and what you want to tell them (where you are, that you need urgent assistance and maybe the nature of the emergency)

On an big plane? Well good luck, they only have analogue radio and it's your problem to cope with the extensive troubles as a result.

I'm actually impressed that COSPAS/SARSAT wasn't obliged to keep the analogue plane transmitters working, despite obsoleting (and no longer providing rescue for) analogue boat or personal transmitters. But on that, at least, they were able to say no, if you don't want to spend a few grand on the upgrade for your million dollar plane we don't plan to spend billions of dollars to maintain the satellites just so you can keep your worse system limping along.

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

#114

Post by ianferrel »

andkenneth wrote: post #98
pvitz wrote: post #70

Earlier quoted context omitted.

Yes, it looks like they should have written "NM" instead of "nm".

No one is using nanometers in aviation navigation. Quite a few aviation systems are case insensitive or all caps only so you can't always make a distinction. In fact, if you say "miles", you mean nautical miles. You have to use "sm" to mean statute miles if you're using that unit, which is often used for measuring visibility.

Sure but I could imagine some kind of software failure caused by trying to divide by a distance that rounded two zero because the same location was listed in two databases that were almost but not exactly the same location. In fact I did when I first read the headline, then realized that it was probably nautical miles.

That would be roughly consistent with the title and not a totally absurd thing to happen in the world.

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

#115

Post by crtified »

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.

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

#117

Post by mcfedr »

amiga386 wrote: post #86

This is old news, but what's new news is that last week, the UK Civil Aviation Authority openly published its Independent Review of NATS (En Route) Plc's Flight Planning System Failure on 28 August 2023 https://www.caa.co.uk/publication/download/23337 (PDF) Let's look at point 2.28: "Several factors made the identification and rectification of the failure more protracted than it might otherwise have been. These inclu…

But no mention of this insane failure mode? If the article is to be believed

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

#118

Post by mcfedr »

mjevans wrote: post #80
jmvoodoo wrote: post #11

So, essentially the system has a serious denial of service flaw. I wonder how many variations of flight plans can cause different but similar errors that also force a disconnect of primary and secondary systems. Seems "reject individual flight plan" might be a better system response than "down hard to prevent corruption" Bad assumption that a failure to interpret a plan is a serious coding error seems to be the root…

Reject the flight plan would be the last case scenario, but where it should have gone without other options rather than total shutdown. CORRECT the flight plan, by first promoting the exit/entry points for each autonomous region along the route, validating the entry/exit list only, and then the arcs within, would be the least errant method.

Reject the plan surely should have come many places before shutdown the whole system!

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

#119

Post by cheschire »

ikiris wrote: post #48
jp57 wrote: post #9

FYI: nm = nautical miles, not nanometers.

Nanometers would be a very short flight.

I could imagine conflict arising when switching between single and double precision causing inequality like this.

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

#120

Post by Arainach »

Shorel wrote: post #108
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…

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.
Post reply on HN