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

UK air traffic control meltdown

jameshaydon.github.io

Post reply on HN
Print view View original

231–240 of 459 posts

Re: UK air traffic control meltdown

#231

Post by seszett »

hermitcrab wrote: post #197

>"in typical Mail Online reporting style: "Did blunder by French airline spark air traffic control issues?" The Daily Mail is a horrible, right-wing paper in the UK that blames 'foreigners' for everything. Particularly the French. Out of curiosity, is there a corresponding French paper that blames the English or the British for everything?

Well not really. People in France don't really care that much about England.

The one country that is often blamed for problems is rather Germany, but honestly even Germany doesn't get blamed for petty problems like that.

Re: UK air traffic control meltdown

#232

Post by crabbone »

theptip wrote: post #169
crabbone wrote: post #167

I want to comment specifically on: > The software and system are not properly tested. Followed by suggesting to do fuzzing tests. * Automatically generating valid flight paths is somewhat hard (and you'd have to know which ones are valid because the system, apparently, is designed to also reject some paths). It's also possible that such a generator would generate valid but improbable flight paths. There's probably an…

None of this really argues against fuzz testing; even with completely bogus/malformed flight plans, it shouldn't be possible for a dead letter to take down the entire system. And, since it's translating between an upstream and downstream format (and all the validation is done when ingesting the upstream), you probably want to be sure anything that is valid upstream is also valid downstream. It's true that fuzz testin…

This is not against the principle of fuzz testing. This is to say that the author doesn't really know the reality of testing and is very quick to point fingers. It's easy to tell in retrospect that this particular aspect should've been tested. It's basically impossible to find such defects proactively.

Re: UK air traffic control meltdown

#233

Post by dharmab »

epanchin wrote: post #215
sam0x17 wrote: post #163

Earlier quoted context omitted.

Why on earth do they not have GUIDs for these navigation points if the names are not globally unique and inter-region routes are commonplace?

What three words would be a better solution than a guid, as transmittable over radio.

W3W contains homonyms and words that are easily confused by non-native english speakers. Often within just a few KM. The latter is why ATC uses "niner", to avoid confusing "nine" and "nein".

Talk to someone deep in the GIS rabbit hole and you'll get a rant about how bad W3W is: https://cybergibbons.com/security-2/why-what3words-is-not-su...

Re: UK air traffic control meltdown

#234

Post by chrisweekly »

epanchin wrote: post #215
sam0x17 wrote: post #163

Earlier quoted context omitted.

Why on earth do they not have GUIDs for these navigation points if the names are not globally unique and inter-region routes are commonplace?

What three words would be a better solution than a guid, as transmittable over radio.

That's "What3Words" -- https://en.m.wikipedia.org/wiki/What3words -- a system for representing geographic location using globally-unique word triads.

Re: UK air traffic control meltdown

#235

Post by cratermoon »

touisteur wrote: post #14
cratermoon wrote: post #2

"the description sounds like the procedure is working directly on the textual representation of the flight plan, rather than a data structure parsed from the text file. This would be quite worrying, but it might also just be how it is explained." Oh, this is typical in airline industry work. Ask programmers about a domain model or parsing, they give you blank stares. They love their validation code, and they love jus…

Giving up if something doesn't validate is indeed standard to avoid propagating badly interpreted data, causing far more complex bugs down the line. Validate soon, validate strongly, report errors and don't try to interpret whatever the hell is wrong with the input, don't try to be 'clever', because there lie the safety holes. Crashing on bad input is wrong, but trying to interpret data that doesn't validate, without…

There's a difference between parsing and validating. https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

You're right about all the buggy stuff out there, and that nobody wants to pay to make it better, though.

Re: UK air traffic control meltdown

#236

Post by crabbone »

drachir91 wrote: post #207

What ticked me is that when the primary system threw in the towel, an EXACT SAME system took over and ran the exact same code on the exact same data as the primary. I know that with code and algorithms it's not always the case but even then you know what doing the same thing over and over expecting different results defines... Yes, it can be argued that the software should've had more graceful failure modes and this…

> an EXACT SAME system took over and ran the exact same code

Did you ever work with HA systems? Because this is how they work. It's two copies of the same system intended for the cases when eg. hardware fails, or network partitioning happens etc.

Re: UK air traffic control meltdown

#237

Post by nwallin »

sam0x17 wrote: post #163
reactordev wrote: post #28

So they forgot to "geographically disparate" fence their queries. Having built a flight navigation system before, I know this bug. I've seen this bug. I've followed the spec to include a geofence to avoid this bug.

Why on earth do they not have GUIDs for these navigation points if the names are not globally unique and inter-region routes are commonplace?

1. Pilots occasionally have to fat finger them into ruggedized I/O devices and read them off to ATC over radios.

2. These are defined by the various regional aviation authorities. The US FAA will define one list, (and they'll be unique in the US) the EU will have one, (EASA?) etc.

The AA965 crash (1995-12-20) was due to an aliased waypoint name. Colombia had two waypoints with the same name within 150 nautical miles of each other. (the name was 'R') This was in violation of ICAO regulations from like the '70s.

https://en.wikipedia.org/wiki/American_Airlines_Flight_965

Re: UK air traffic control meltdown

#238

Post by cratermoon »

3pac wrote: post #8
cratermoon wrote: post #6

Earlier quoted context omitted.

It was terrifying enough for me in the gig I worked on that dealt with reservations and check-in, where a catastrophic failure would be someone boarding a flight when they shouldn't have. To avoid that sort of failure, the system mostly just gave up and issued the passenger what's called an "Airport Service Document": effectively a record that shows the passenger as having a seat on the flight, but unable to check-in…

SABRE is pretty good compared to the card file it replaced.

It's better to say SABRE replicated, in digital form, that card file. And even today the legacy of that card form defines SABRE and all the wrappers and gateways to it.

Re: UK air traffic control meltdown

#239

Post by jameshart »

asimpleusecase wrote: post #3

And why could the system not put the failed flight plan in a queue for human review and just keep on working for the rest of the flights? I think the lack of that “feature” is what I find so boggling.

The algorithm as described in the blogpost is probably not implemented as a straightforward piece of procedural code that goes step by step through the input flightplan waypoints as described. It may be implemented in a way that incorporates some abstractions that obscured the fact that this was an input error.

If from the code’s point of view it looked instead like a sanity failure in the underlying navigation waypoint database, aborting processing of flight plans makes a lot more sense.

Imagine the code is asking some repository of waypoints and routes ‘find me the waypoint where this route leaves UK airspace’; then it asks to find the route segment that incorporates that waypoint; then it asserts that that segment passes through UK airspace… if that assertion fails, that doesn’t look immediately like a problem with the flight plan but rather with the invariant assumptions built into the route data.

And of course in a sense it is potentially a fatal bug because this issue demonstrates that the assumptions the algorithm is making about the data are wrong and it is potentially capable of returning incorrect answers.

Re: UK air traffic control meltdown

#240

Post by Rochus »

seabass-labrax wrote: post #212
Rochus wrote: post #67

This is apparently just an opinion, no additional inside information than we had from the report ( https://news.ycombinator.com/item?id=37401981 ), isn't it? EDIT: downvoting this question instead of responding is a pretty strange reaction.

You are correct, but it's an opinion that bridges the gap editorially between those knowledgable about ATC but not data, and those knowledgable about data but not ATC. This is a valuable service to provide, as both fields are rather complex.

Thanks. I didn't have the patience to read it all. I initially hoped that the author was a field expert or even someone with inside knowledge, but he is apparently from a completely different domain and not in the UK, and there were assumptions about things the report was rather specific about (as specific as such reports usually are). It would be more useful if people would take a closer look at the report and draw the right conclusions about organizational failures and how to avoid them. All the great software technologies to achieve memory safety, etc. are of little use if the analyses and specifications are flawed or the assumptions of the various parties in a system of systems do not match. But people seem to prefer to speculate and argue about secondary issues.
Post reply on HN