[jmvoodoo]

So, essentially the system has a serious denial of service flaw. I wonder how many variations of flight plans can cause different but similar errors that also force a disconnect of primary and secondary systems.

Seems "reject individual flight plan" might be a better system response than "down hard to prevent corruption"

Bad assumption that a failure to interpret a plan is a serious coding error seems to be the root cause, but hard to say for sure.

[mjevans]

Reject the flight plan would be the last case scenario, but where it should have gone without other options rather than total shutdown.

CORRECT the flight plan, by first promoting the exit/entry points for each autonomous region along the route, validating the entry/exit list only, and then the arcs within, would be the least errant method.

[d1sxeyes]

You can’t just reject or correct the flight plan, you’re a consumer of the data. The flight plan was valid, it was the interpretation applied by the UK system which was incorrect and led to the failure.

There are a bunch of ways FPRSA-R can already interpret data like this correctly, but there were a combination of 6 specific criteria that hadn’t been foreseen (e.g. the duplicate waypoints, the waypoints both being outside UK airspace, the exit from UK airspace being implicit on the plan as filed, etc).

[sandos]

If this is the case, then every system along the flightplan should pre-validate it before it gets accepted at the source?

[d1sxeyes]

That adds a huge amount of overhead in terms of messaging and possibly adds delays in flight plans being accepted.

The way this is supposed to work is that downstream systems should accept valid flight plans.

I would say that it’s not the upstream system’s responsibility to reject valid flight plans because of implementation details on a downstream system.

[d1sxeyes]

The more I think about it, the more convinced I am that completely failing is the correct approach. There are two possible causes for the system not being able to process a flight plan:

1. The flight plan was really invalid. In this case the assumption must be that the upstream system is sending invalid flight plans, which can’t be processed by a correctly programmed downstream app. All data from upstream must now be treated as potentially incorrect

2. The flight plan was not invalid and there is some unforeseen issue in the downstream system (this was actually the case). If this is true, then the downstream system cannot assume it is behaving correctly when receiving valid flight plans, so can’t continue to process flight plans in case it incorrectly process another plan in a more subtle way.

Both cases need urgent manual intervention and should result in a manual review before more flight plans could potentially be processed incorrectly.

[mcfedr]

Reject the plan surely should have come many places before shutdown the whole system!