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

341–350 of 459 posts

Re: UK air traffic control meltdown

#341

Post by wcarss »

dhx wrote: post #335
WalterBright wrote: post #322

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

This would have been a 2oo2 system where the pilot becomes the backup. 2oo2 systems are not highly available. Air traffic control systems should at least be 2oo3[1] (3 systems independently developed of which 2 must concur at any given time) so that a failure of one system would still allow the other two to continue operation without impacting availability of the aviation industry. Human backup is not possible becaus…

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!

Re: UK air traffic control meltdown

#342

Post by jangxx »

wcarss wrote: post #341
dhx wrote: post #335

Earlier quoted context omitted.

This would have been a 2oo2 system where the pilot becomes the backup. 2oo2 systems are not highly available. Air traffic control systems should at least be 2oo3[1] (3 systems independently developed of which 2 must concur at any given time) so that a failure of one system would still allow the other two to continue operation without impacting availability of the aviation industry. Human backup is not possible becaus…

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.

Re: UK air traffic control meltdown

#343

Post by mannykannot »

WalterBright wrote: post #329
wavemode wrote: post #327

Earlier quoted context omitted.

First thought that came to my mind as well when I read it. This failover system seems to be more designed to mitigate hardware failures than software bugs.

I also understand that it is impractical to implement the ATC system software twice using different algorithms. The software at least checked for an illogical state and exited, which was the right thing to do. A fix I would consider is to have the inputs more thoroughly checked for correctness before passing them on to the ATC system.

> A fix I would consider is to have the inputs more thoroughly checked for correctness before passing them on to the ATC system.

Thoroughly checking of the inputs as far as possible should be a given, but in this case, the inputs were correct: while the use of duplicate identifiers is considerably less than ideal, the constraints on where that was permitted meant that there was one deterministically unambiguous parsing of the flight plan, as demonstrated in the article. The proximate cause of the problem was not in the inputs, but how they were processed by the ATC system.

For the same reason, multiple implementations of the software would only have helped if a majority of the teams understood this issue and got it right. I recall a fairly influential paper in the '90s (IIRC) in which multiple independent implementations of a requirements specification were compared, and the finding was that the errors were quite strongly correlated - i.e. there was a tendency for the teams to make the same mistakes as each other.

Re: UK air traffic control meltdown

#344

Post by xp84 »

nightpool wrote: post #331
WalterBright wrote: post #329

Earlier quoted context omitted.

I also understand that it is impractical to implement the ATC system software twice using different algorithms. The software at least checked for an illogical state and exited, which was the right thing to do. A fix I would consider is to have the inputs more thoroughly checked for correctness before passing them on to the ATC system.

not stronger isolation between different flight plans? it seems "obvious" to me that if one flight plan is causing a bug in the handling logic, the system should be able to recover by continuing with the next flight plan and flagging the error to operators to impact that flight only

I'm no aviation expert, but perhaps with waypoints:

  A B C D E
   /
  F G H I J
If flight plan #1 is known to be going from F-B at flight level 130, and you have a (supposedly) bogus flight plan #2, they can't quite be sure if it might be going from A-G at flight level 130 at the same time and thus causing a really bad day for both aircraft. I'd worry that dropping plan #2 into a queue for manual intervention, especially if this kind of thing only happens once every 5 years, could be disastrous if people don't realize what's happening and why. Many people might never have seen anything in that queue and may not be trained to diagnose the problem and manually translate the flight plan.

This might not be the reason why the developer chose to have the program essentially pull the fire alarm and go home in this case, but that's the impression I got.

Re: UK air traffic control meltdown

#345

Post by nimchimpsky »

sam0x17 wrote: post #334
f1shy wrote: post #174

Earlier quoted context omitted.

The names have to be entered manually by pilots, if e.g. they change the route. They have to be transmitted over the air by humans. So they must be short ans simple.

Sounds like we should have globally unique human-enterable identifiers governed by an ISO..

[dead]

Re: UK air traffic control meltdown

#346

Post by cellularmitosis »

garyfirestorm wrote: post #333

> Safety critical software systems are designed to always fail safely. This means that in the event they cannot proceed in a demonstrably safe manner, they will move into a state that requires manual intervention. unrelated - this instantly caused me to think about tesla autopilot crashes that have been reported with emergency vehicles

It made me think of the “put a traffic cone on it” denial of service attack

Re: UK air traffic control meltdown

#347

Post by nimchimpsky »

epolanski wrote: post #312
crabbone wrote: post #232

Earlier quoted context omitted.

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.

I've read both messages and I'm still unsure on how fuzzy testing may have not brought up similar edge cases. We literally talking about a parser shutting down an entire system rather than reporting malformed data. Considering this is a "one in 15M cases" it seems to me that fuzzy testing would've caught this and probably more bugs in a short time span.

[dead]

Re: UK air traffic control meltdown

#348

Post by [deleted] »

jacquesm wrote: post #126

Trusted input rarely should be trusted. It's input. You need to validate it as if it is hostile and have a process for dealing with malformed input. Now of course, standing by the sidelines it is easy to criticize and I'm sure whoever worked on this wasn't stupid. But I've seen this error often enough now in practice that I think that it needs to be drilled into programmers heads more forcefully: stuff is only valid…

[deleted]

Re: UK air traffic control meltdown

#350

Post by chii »

borissk wrote: post #336
WalterBright wrote: post #322

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

Different teams often make the same mistake. The system you describe is not perfect, but makes sense.

if this is true, then would it be a better investment to have the 2nd team produce a fuzz testing/systematic testing mechanism instead of producing a secondary copy of the same system?

In fact, make it adversarial testing such that this team is rewarded (may be financially) if mistakes or problems are found from the 1st team's program.

Post reply on HN