3 ms·

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 f

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 2y ago
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.
- mcfedr 2y ago
  Reject the plan surely should have come many places before shutdown the whole system!
- d1sxeyes 2y ago
  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 2y ago
    If this is the case, then every system along the flightplan should pre-validate it before it gets accepted at the source?
    - d1sxeyes 2y ago
      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 2y ago
        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.

mjevans 2y ago

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.

mcfedr 2y ago
Reject the plan surely should have come many places before shutdown the whole system!
d1sxeyes 2y ago
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 2y ago
  If this is the case, then every system along the flightplan should pre-validate it before it gets accepted at the source?
  - d1sxeyes 2y ago
    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 2y ago
      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.