4 ms·
OK, that makes sense. And understood on route vs position. But wouldn't your design still require additional complexity in the system? It would need to keep tra
by gnfargbl 3y ago
OK, that makes sense. And understood on route vs position. But wouldn't your design still require additional complexity in the system? It would need to keep track of all bad flight plans, and also keep a database of the status of those plans. The controllers would need to update the status to tell the system that they had phoned and cancelled the bad plan. That (small) additional complexity would cost money and add risk.
It sounds to me like the engineers made a design decision between "add handling mechanisms for valid-but-unexpected flight plans" and "ensure we can handle absolutely every valid flight plan"? If so, this is a rare case where I sympathise with the engineering team behind a major IT failure.
- krisoft 3y agoYes, absolutely. And that is the tricky issue. Because the plan was filed with the Eurocontrol’s IFPS system which handed it over to the UK's system. Flight crew and dispatchers report that flight plans are regularly rejected, and then they need to file a new one. But it sounds like this rejection happens in a layer before the one which failed in this case. So this is basically a system which is not meant to be able to reject a flight plan, since the plans it receives were already checked and validated.
- Closi 3y ago"We won't need to reject a flight plan as the data we receive will always be perfect!" sounds like an approach to error handling that will lead to these sort of situations. The issue should have been caught in one of the higher systems, and then the error should have also been handled in a more appropriate way.
- gnfargbl 3y agoThank you for this. It all makes a lot more sense now.