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

151–160 of 311 posts

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

#151

Post by jp57 »

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.

Indeed, having locations internally represented in software with a resolution of nanometers is as ridiculous as having your calendar's internal times represented as milliseconds since some arbitrary moment more than fifty years ago!

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

#153

Post by amiga386 »

mcfedr wrote: post #117
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

I'm not sure what you think is the insane failure mode?

The UK is part of the IFPS Zone, centrally managed by EUROCONTROL using AFTM. IFPS can accept/reject IFR flight plans, but the software at NATS can't. By the time NATS gets the flight plan, it has already been accepted. All their software can do is work out which parts enter the UK's airspace. If it's a long route, the plane has already taken off.

NATS aren't even thinking of a mixed-mode approach (for IFR flight plans) where they have both automated processing and manual processing of things the automated processing can't handle. They don't have a system or processes capable of that. And until this one flight, they'd never had a flight plan the automated system couldn't handle.

The failures here were:

1) a very unlikely edge case whose processing was specified, but wasn't implemented correctly, in the vendor's processing software

2) no test case for the unlikely edge case because it was really _that_ unlikely, all experts involved in designing the spec did not imagine this could happen

3) they had the same vendor's software on both primary and secondary systems, so failover failed too; a second implementation might have succeeded where the first failed, but no guarantees

4) they had a series of incident management failures that meant they failed to fix the broken system within 4 hours, meaning NATS had to switch to manual processing of flight plans

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

#154

Post by Nevermark »

skykooler wrote: post #150
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.

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

We better get this sorted out before open source manned Mars missions.

That all programming languages, down to statically typed assembly, don’t support something as simple to validate as unit consistency says something strange about how the science of replacing unreliable manual processes with automated systems is really bad at the practice of replacing its own risky manual processes with automated systems.

If numeric types just required a given unit, without even supporting automated conversions, it would make incorrectly unit-ed/scaled literals vastly less likely.

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

#155

Post by crubier »

convivialdingo wrote: post #116

I guarantee that piece of code has a comment like /* This should never happen */ if (waypoints.matchcount > 2) {

Possibly even just

    waypoint = waypointsMatches[0]
Without even mentioning that waypointsMatches might have multiple elements.

This is why I always consider [0] to be a code smell. It doesn't have a name afaik, but it should.

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

#156

Post by ggm »

Could you front-end the software with a proxy which bounces code-collision requests and limit the damage to the specific route, and not the entire systems integrity?

This is hack-on-hack stuff, but I am wondering if there is a low cost fix for a design behaviour which can't alter without every airline, every other airline system worldwide, accommodating the changes to remove 3-letter code collision.

Gate the problem. Require routing for TLA collisions to be done by hand, or be fixed in post into two paths which avoid the collision. (intrude an intermediate waypoint)

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

#157

Post by joemi »

jp57 wrote: post #9

FYI: nm = nautical miles, not nanometers.

It's quite amusing that they used the incorrect, lowercase abbreviation for "nautical mile" which means something else ("nanometer") in an article about a major issue caused by two things sharing the same abbreviation.

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

#158

Post by amarshall »

perihelions wrote: post #12

Original (2023) thread with 446 comments, https://news.ycombinator.com/item?id=37461695 ( "UK air traffic control meltdown (jameshaydon.github.io)" )

And the article itself in the older thread is a far more interesting read than this OP.

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

#159

Post by joemi »

andkenneth wrote: post #101
fyt2024 wrote: post #97

Is nm the official abbreviation for nautical miles? I assume it is natural miles. For me it is nanometers.

Contextually no one is using nanometers in aviation nav applications. Many aviation systems are case insensitive or all caps only so capitalisation is rarely an important distinction.

Similarly, no pilot in the Devil’s Lake region is using DVL to mean Deauville, and vice versa. :)

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

#160

Post by astrange »

exe34 wrote: post #138
Arainach wrote: post #120

Earlier quoted context omitted.

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.

I think a more subtle issue is that fixing old bugs can cause new bugs. It's easier to fix something new, for instance because you understand it better. At some point it can be safest to just not touch something old.

Also, old bugs can get fixed by accident / the environment changing / the whole subsystem getting replaced, and if most of your long tail of bugs is already fixed then it wastes people's time triaging it.

Post reply on HN