How many times...

Nats acknowledged a “technical issue” had occurred but said it was not caused by a cyber attack.

Are you suggesting they are lying?

Not for a moment, both recent rail problems were also satisfactorily explained. It just seems that coincidence is being stretched.

Hanlons razor

Bring back Kenneth Williams in "Carry in Cleo" with "Infamy! Infamy! They've all got it in for me!"

Well how many times before proper money is spent on it Mind you there are AWACs flapping over Romania and Finland, and 8 Eurofighters were up today. Over the N sea...

Exactly. They don't need to mount a cyber attack on our ATC system, they just have to wait for it to fall over all by itself.

I suppose if some state or other wanted to interfere in s plausibly deniable way then they could bung MPs enough moolah to persuade them not to vote for investment in the upgrade/replacement that the system desperately needs but MPs seem to be effectively doing that already.

Nick

Well, we now the facts. It was a Biggles fat-finger fault. Own goal.

I didn't read that anywhere in the article....

Latest I've read is NATS are blaming spurious data from a military flight?

Interesting, we have Chinooks over here quite frequently and their actual location is always different to that shown by Flightradar 24 by a few minutes, security?

I had heard third hand that it was bad data, but have seen no actual detailed explanation Perhaps its time to fire up the Vulture... ...mmm. The scuttlebutt has it as a military flight. Posting improbable data. Probably filing a flight plan above 64000 feet or something

Military flights that DO have transponders on are always dead accurate here. I hear engine noise and look it up on ADSB exchange and know what is overhead. Usually some WWII warbird. Or the odd apache

Remember it is up to the aircraft to say where it is. On ADSB, I am not sure if MLAT isn't related to surveillance radar.

It may lie. Or be confused.

I don't think the system that failed is the one that controls flight levels and headings, but the one that accepts details of planned flights from the airlines (and military) obviously one feeds into the other.

Isn't all of flightradar24 delayed? You could buy a cheap RTL-SDR and build an ADS-B aerial from a coke can and a stub of stiff wire, receive the data yourself direct from the aircraft ...

And exactly the same fault as last screwed up ATC, a couple of years ago.

That sounds like a return to the days of Kettering High School!

So it _was_ enemy action - but who's enemy?

(Or should that be "Enemy to whom?)

I don't suppose 'anyone' would take note of such things, and aim to repeat then at some critical moment when 'they' are doing something we wouldn't like.

the incident was caused by a legacy and previously unknown defect in a software module within the NAS which processes requests for the allocation or reassignment of squawk codes. A squawk code is an identification code transmitted (squawked) by the aircraft during flight, enabling air traffic control systems to match the aircraft?s altitude, speed and direction with its intended flight plan so that flight progress can be monitored.

The incident was triggered by a valid manual request for a squawk code. This manual request was made correctly and there was nothing abnormal or invalid about the associated flight plan.

While this request was being processed, the NAS received a message for a higher priority activity to be undertaken which resulted in the squawk code allocation being paused while the system processed the higher priority message. Switching between different activities in response to prioritised requests is a normal function of the system; however, when the processing of the squawk allocation request resumed, the software defect meant it did not resume correctly and the resulting output was corrupted.

The reason this scenario has not occurred before is because:

1. The defect existed in a specific subsection of code within a software module, with an exposure window estimated as approximately one millisecond.

1. For the fault to occur, a higher-priority request had to arrive during that exact millisecond while the original request was part-way through updating a value.

2. Had the higher-priority request arrived even one millisecond earlier or later, the update would have completed normally.

Post-incident investigation has identified that when processing of the squawk allocation request resumed, the data associated with it had been corrupted and affected some subsequent flight data updates.

So something assuming timestamp to the millisecond will be unique? Surprised it didn't happen earlier ...

I'd read that as some of the code is not properly thread-safe.