Sounds like a fairly common error case to check for although they say that it never happened before.
ID collisions are always something to check for, not least when the data are user inputs.
And the ID collision was in user data which the air traffic system has to continuously accept during operations.
And it sounds like that data breaks down into individual flight plans - so it might be trivial to reject just one flight plan, and allow the rest to proceed.
BUT...doubtless the UK's flight control software came out of some multi-billion-pound government boondoggle. So we should be grateful that it doesn't crash planes into each other, or send innocent postal workers to jail for theft, and overlook these sorts of failures.
It's all well and good to say that software just shouldn't have bugs, but that's pretty much an unsolved problem at this point. The NATS system has a relatively good track record, and even companies with exemplary engineering standards have occasionally had large system failures.
Let he who is without sin cast the first stone.
Consider reading the actual initial Nats report https://publicapps.caa.co.uk/docs/33/NERL%20Major%20Incident... – this provides a bunch of interesting analysis and technical information.
I'm sorry for being mean about it, but it's a personal bugbear of mine when complex systems failures are boiled down to lazy analysis.
rejecting a plan wouldn't necessarily mean it doesn't exist/take off anymore, so that doesn't sound sensible
They could have probably found this sooner with either fuzzing or perhaps some sort of digital twin model.
Finally, there's no exit clause to reject a flight plan from an "upstream"? That is a worry.
e.g. if I want to drive to Springfield, it needs to know which one out of 67 I'd like to go to...
We get so many invalid flight plans from third parties (e.g., ForeFlight) that the system would never be up if we didn’t mark them as invalid and move on to the next.
https://news.ycombinator.com/item?id=37320322
https://news.ycombinator.com/item?id=37328377
