Live data from Hacker News

UK air traffic control meltdown

jameshaydon.github.io

401–410 of 459 posts

Re: UK air traffic control meltdown

#401
post #76

I seem to remember another problem at NATS which had the same effect. Primary fell over so they switched over to a secondary that fell over for the exact same reason. It seems like you should only failover if you know the problem is with the primary and not with the software itself. Failing over "just because" just reinforces the idea that they didn't have enough information exposed to really know what to do. The bit…

The Ariane 5 launch failure[1] was a similar issue, albeit with a more spectacular outcome.

Primary suffers integer overflow, fails. Secondary is identical, which also overflows. Angle of attack increases, boosters separate. Rocket goes boom.

[1] https://en.wikipedia.org/wiki/Ariane_flight_V88

Re: UK air traffic control meltdown

#402
post #342
post #341

Earlier quoted context omitted.

This reminds me of a backwoods hike I took with a friend some years back. We each brought a compass, "for redundancy", but it wasn't until we were well underway that we noticed our respective compasses frequently disagreed. We often wished we had a third to break the tie!

Sounds like the joke about a man with one watch always being sure about what time it is, but a man with two being continuously in doubt.

Just computate the average, then counter the documented drift vs a external source?

Re: UK air traffic control meltdown

#403
post #247
post #244

Earlier quoted context omitted.

Dude this isn't reddit dont worry about the votes.

Since it's not Reddit but HN, it's all the stranger to dismiss a perfectly legitimate question. But times and mores seem to change much faster than I realize.

It's because your question was poorly phrased - it sounds like you are trying to dismiss the value of the submission for no apparent reason. If you genuinely want to know the answer to a question, don't start with your conclusion and append "isn't it?" to turn it into a question. Just say something like "I don't have time to read the article. Does the author provide any industry expertise to the incident beyond what was in the original report?".

Re: UK air traffic control meltdown

#404
Has the culprit flight-plan been disclosed? I'd be interested to know how easy it is to create a realistic looking flight-plan through UK airspace that reproduces the problem. I.e. how much truth is there when NATS say this was a 1 in 15m probability?

Re: UK air traffic control meltdown

#405
post #400
post #341

Earlier quoted context omitted.

This reminds me of a backwoods hike I took with a friend some years back. We each brought a compass, "for redundancy", but it wasn't until we were well underway that we noticed our respective compasses frequently disagreed. We often wished we had a third to break the tie!

My grandfather was working with Stanisław Skarżyński, who was preparing for his first crossing of the Atlantic in a lightweight airplane (RWD-5bis, 450kg empty weight) in 1933. They initially mounted two compasses in the cockpit, but Skarżyński taped one of them over so that it wasn't visible, saying wisely that if one fails, he will have no idea which one is correct.

That's a cool story! Would have loved to have heard more about that :)

Re: UK air traffic control meltdown

#406
post #296

Earlier quoted context omitted.

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

I always love it when someone helicopters in to a complex, long-established system and, without even attempting to understand the requirements, constraints or history, knows this thing they read on a blog one time would fix all the problems thousands of work-years have failed to address.

Well, it would be hard for them to helicopter in with their navigation system. ATC would have a field day. ;)

Re: UK air traffic control meltdown

#407

Earlier quoted context omitted.

> Air traffic control systems should at least be 2oo3... Human backup is not possible because of human resourcing and complexity. But this was a 1oo1 system, and the human backup handled it well enough: a lot of people were inconvenienced, but there were no catastrophes, and (AFAIK) nothing that got close to being one. As for the benefits of independent development: it might have helped, but the chances of this being…

> But this was a 1oo1 system, and the human backup handled it well enough ... Heh, a hundred million pound outage. ;) True, no-one seems to have died from it directly though.

True. I don't want to downplay the actual cost (or, worse, suggest that we should accept "the system worked as intended" excuses), but it's not just that there were no crashes: the air traffic itself remained under control throughout the event. Compare this to, for example, the financial "flash crash" of 2010, or the nuclear 'excursions' at Fukushima / Chernobyl / Three Mile Island / Windscale, where those nominally in control were reduced to being passive observers.

It also serves as a reminder of how far we have to go before we can automate away the jobs of pilots and air traffic controllers.

Re: UK air traffic control meltdown

#408

Earlier quoted context omitted.

In this case the problem was choosing an excessively naive algorithm. I'm very inexperienced but that seems to me like the solution would be to spend a bit more money on reviewing the one implementation rather than writing two new ones from scratch.

you would be very surprised how difficult avionics are from even a fundamental level. I'll provide a relatively simple example. Just even attempting to design a starfox game clone where the ship goes towards the mouse cursor using euler angles will almost immediately result in gimbol lock and your starfighter locking up tighter than unlubricated car engine going 100mph and unable to move. [0] The standard solution in…

I was doing some orientation sensing 20 years ago with an IMU and ran into the same problem. I had never known at the time it was gimbal lock (which I had heard of) but did read quaternions were the way to fix it. Pesky problem.

Re: UK air traffic control meltdown

#409
post #155

Earlier quoted context omitted.

That reasoning is fine, but it rather seems that the programmers triggered this catastrophic "stop the world" error because they were not thorough enough considering all scenarios. As TA expounds, it seems that neither formal methods nor fuzzing were used, which would have gone a long way flushing out such errors.

Neither formal methods nor fuzzing would've helped if the programmer didn't know that input can repeat. Maybe they just didn't read the paragraph in whatever document describes how this should work and didn't know about it. I didn't have to implement flight control software, but I had to write some stuff described by MIFID. It's a job from hell, if you take it seriously. It's a series of normative documents that expl…

The point of fuzzing is precisely to discover cases that the programmers couldn't think about, and formal methods are useful to discover invariants and assumptions that programmers didn't know they rely on.

Furthermore, identifiers from external systems always deserve scepticism. Even UUIDs can be suspect. Magic strings from hell even more so.

Re: UK air traffic control meltdown

#410

> the backup system applied the same logic to the flight plan with the same result Oops. In software, the backup system should use different logic. When I worked at Boeing on the 757 stab trim system, there were two avionics computers attached to the wires to activate the trim. The attachment was through a comparator, that would shut off the authority of both boxes if they didn't agree. The boxes were designed with:…

As as side note, too bad they knowingly didn't reuse such an approach for the MAX..
Post reply on HN