[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.