It is reported that Nats, formerly known as National Air Traffic Services in the UK, has explained the recent national delays on matching marker names on a flight plan:

In its initial report published on Wednesday, Nats said that at 08:32 on 28 August, its system received details of a flight which was due to cross UK airspace later that day.

Airlines submit every flight path to the national control centre; these should automatically be shared with Nats controllers, who oversee UK airspace.

The system detected that two markers along the planned route had the same name - even though they were in different places. As a result, it could not understand the UK portion of the flight plan.

From the point of view of a software developer who knows nothing about flying, it sounds like a relatively common coding error where one expects two random labels to be different and therefore uses them as identifiers, but they are the same more frequently than you expect because of the Birthday problem (or bad RNGs). However if there is something in the specification that means such a collision should not occur then the mistake is not with the developer of the system.

What happened here? Did someone submit an invalid flight plan that broke the system and could have broken any system? Is it a beginner coding mistake in our national infrastructure? Does this actually happen quite frequently and we have been dodging the bullet for five years since the system started? Is there another explanation?

  • $\begingroup$ When I last checked about 3 years ago, there were 4,242 intersection names that were used more than once globally. See this answer for details. $\endgroup$
    – Bianfable
    Sep 6, 2023 at 16:49

2 Answers 2


Did someone submit an invalid flight plan that broke the system and could have broken any system? Is it a beginner coding mistake in our national infrastructure? Does this actually happen quite frequently and we have been dodging the bullet for five years since the system started? Is there another explanation?

It's none of these things, as the report states.

Did someone submit an invalid flight plan that broke the system and could have broken any system?

No, the flight plan appears to have been fundamentally valid, but unfortunately had two waypoints of the same name towards the start and the end. This meant the software was unable to plot a route and accurately cater for the flight.

Is it a beginner coding mistake in our national infrastructure?

I think it's wrong to call this is a "coding" mistake. The software was working as designed - whoever wrote the code implemented the design and intent of the software accordingly. It seems there is no in-built logical way of dealing with this that can be safely automated, but NATS acknowledge that the raising of a critical event was unforeseen.

I.e., the issue really boils down to the fact the error was unforeseen and was essentially unhandled. Because of this, the system went into a fail safe. The better approach, now the issue is understood, is to raise a flag for that particular plan for human intervention.

Does this actually happen quite frequently and we have been dodging the bullet for five years since the system started?

No, this is the first time since the software was implemented 5 years ago that this particular scenario came up. I think that fact alone, over millions of flights, explains why nobody sat down and drew this scenario up on a whiteboard

  • $\begingroup$ This is a good answer, but to clarify it is the first time this has happened for a route that included them IN THE UK. It could be that this is a frequent occurrence in for example Belgium where there are 2 SIERAs only 18.5 NM away from one another as per the answer linked in a comment. $\endgroup$
    – User65535
    Sep 6, 2023 at 17:36
  • $\begingroup$ Another interesting point would be if these two waypoints were both allocated their names by the UK aviation authority. $\endgroup$
    – User65535
    Sep 6, 2023 at 17:39
  • 1
    $\begingroup$ @User65535 Those two SIERAs are VFR points, so they wouldn't be on an IFR flight plan. In general, I'd guess most duplicate names come from either VFR points or points on procedures (SID/STAR/Approach), which are also not part of the IFR flight plan (the plan just contains the procedure name, if at all). $\endgroup$
    – Bianfable
    Sep 6, 2023 at 18:02

I'm afraid that this isn't an aviation question, it's more of an IT question and a hard one to answer as the systems involved are proprietary.

I am a software engineer myself, almost 15 years now, half of them in the development of aviation software -yet not safety critical. I will try to address the main question regarding the duplicate marker names.

Uniqueness of waypoints

Waypoints that are expected to be unique within the airspace system under consideration according to ICAO ANNEX 11 – AIR TRAFFIC SERVICES APPENDIX 2. PRINCIPLES GOVERNING THE ESTABLISHMENT AND IDENTIFICATION OF SIGNIFICANT POINTS Paragraph 3:

3. Designators for significant points not marked by the site of a radio navigation aid

3.1 Where a significant point is required at a position not marked by the site of a radio navigation aid, the significant point shall be designated by a unique five-letter pronounceable “name-code”. This name-code designator then serves as the name as well as the coded designator of the significant point.

3.4 The name-code designator assigned to a significant point shall not be assigned to any other significant point.

There are other paragraphs as well but these 2 are the important ones to know that the point uniqueness is mandated.

You might be wondering then "how did the 2 SIERAs come that close in Bianfable's answer"? If you have a look at the Belgian AIP then you will see that the 2 waypoints have a different parent. The point at northwest belongs to EBST SINT-TRUIDEN / Brustem and the point at southeast belongs to EBLG/ Liège airport.

When a VFR flies within the area of EBLG and they are in contact with the tower and ATC instructs them to "report SIERA" there is no way to confuse it with the "other" SIERA. The "context" is the airport and the waypoints are unique within their context. Finally, please note that these 2 points are VFR; they will never appear in an IFR flight plan like the one in question.

As you can see, while uniqueness can be maintained within the same context, when you "merge" the contexts together like it happens with long distance flights, it's not guaranteed that you will not get any duplicates. As a result, you would expect that a system handling such data would be able to deal with duplicates. Still, it's not black or white.

What could have gone wrong

Unfortunately we can't tell for sure. We are lacking important information like the raw flight plan, the waypoint names and their locations. Also I don't work neither for NATS nor Frequentis that developed the system so I don't have inside information.

I read the report that Dan linked and there are things that need further clarification. Read page 9 and you will see what I mean. One of these points is:

Next, it searches backwards, from the end of that section, to find the UK airspace exit point.

This confuses me. There is no need to search backwards unless you want to compute the 3D trajectory of a descending flight and that can be done in a subsequent state for simplicity. Once you find the first point in the FIR, then you can move forward until you find the first foreign point. Granted, as DeltaLima correctly pointed out in a comment, a flight might exit the FIR and enter back again later on. In any case I would expect the system to not quit after finding the first exit point but make sure that the rest of the points are irrelevant. Can be done in direct or reverse order.

I don't say that I know better than them. But I feel that the wording in the report is (overly?) simplified and that there is certainly more than meets the eye.

On page 6:

The FPRSA-R sub-system exists to convert the data received from IFPS (in a format known as ATS Data Exchange Presentation, ADEXP) into a format that is compatible with the UK National Airspace System (NAS)

But later on

The flight plans delivered to FPRSA-R by IFPS are converted from an ICAO document 4444 (ICAO4444) format to a format known as ADEXP.

Again I'm confused. The first statement implies that FPRSA-R receives plans from IFPS in ADEXP format and and in the second statement in ICAO format. That might seem trivial but things can be lost or taken wrong in translation.

Moreover, according to the same report, IFPS handled the same flight plan without issues so it could not have broken any system; it was tried and it didn't.

Last but not least, we need to have access to the problematic data and as far as I see the flight plan has not been published up until this moment. This is important as according to the same report, the system has processed successfully 15 million flight plans up until now. I find it hard to believe that this was the first time that the system encountered a plan with duplicate points. I might be wrong though as the airlines might be vetting the flight plans, just to be on the safe side. I don't know that for sure.

The most important question that I feel it needs to be answered by the relevant parties (not by anonymous people on the internet) is why a single faulty input resulted in taking out both their main and the backup systems.

We certainly need more information in order to avoid speculation.

  • $\begingroup$ Hi Stelios, the reason for doing a backward search from the end, instead of a forward search from the point of entry, may be related to the possibility of a flight leaving UK airspace and then re-entering it. By searching backwards from the end, you are sure to have the segment between the first entry and the last exit. $\endgroup$
    – DeltaLima
    Sep 7, 2023 at 14:40
  • $\begingroup$ Regarding the conversion: your interpretation of the quote is incorrect: the IFPS converts the ICAO flight plan to ADEXP before forwarding it to the UK FPRSA-R. The wording in the report would perhaps better be: The flight plans delivered to FPRSA-R by IFPS *have been* converted from an ICAO document 4444 (ICAO4444) format to a format known as ADEXP. $\endgroup$
    – DeltaLima
    Sep 7, 2023 at 14:47
  • $\begingroup$ My suspicion is that the FPRSA-R system allows for flightplans that have the same waypoint multiple times in the route (e.g. for accommodating a surveillance flight do multiple rounds). To reduce the load on the aeronautical database, the coordinates of each waypoint are queried only once per flight plan and are locally cached during the flight plan's processing. If the coordinates for a named waypoint are already in the cache, there is no need to ask the database again. That logic only works if duplicate waypoint names within the plan are refering to the same geographical position. $\endgroup$
    – DeltaLima
    Sep 7, 2023 at 14:57
  • $\begingroup$ (1/2) @DeltaLima Hello Douwe, good to hear from you after all this time. :) Regarding comment 1: I updated the answer though I believe the order isn't relevant. Regarding comment 2, that's exactly my beef. The wording leaves room for misunderstanding and the report seems to be targeting a broader audience and not just niche. It could have been more carefully worded. In my humble opinion. Regarding comment 3, I still believe that it's too obvious a case to miss. Unless it's the first one after the 15 million where name1 = name2 and location1 <> location2. $\endgroup$ Sep 7, 2023 at 16:02
  • $\begingroup$ (2/2) Then what can I say. Perhaps the 4000+ duplicate points on the planet are not enough to create that condition more than once in 15 million. Regardless, what you are describing is caching and allow me to believe that this isn't the case: the algorithm processing the plan should be oblivious of how the points are accessed. It should be able though to know which point to retrieve. Both of them are said to be outside the UK FIR so I doubt it if they are in the aeronautical database. $\endgroup$ Sep 7, 2023 at 16:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .