Swanwick Software Update After 2002 Near- Miss??

[mr Q]

Air traffic software to change after near-miss

Simon Busch and agencies
Monday January 19, 2004
GUARDIAN ONLINE

Air traffic control software is to be changed following an incident in which two large passenger jets almost collided, it was revealed today.
A mix-up at the Swanwick air traffic control centre, in Hampshire, put a Virgin Atlantic Boeing 747 and a Delta Airlines Boeing 767 on a collision course over Wales in November 2002.

A cockpit collision avoidance system alerted the Virgin pilot to the danger. As a result, the plane had to climb so quickly that a woman passenger was thrown off balance and broke an ankle.

Computer Weekly magazine today revealed that an upgrade to Swanwick software will be made by National Air Traffic Services (Nats) next month.

The magazine said that the controller in the incident thought his instructions to the pilots of the aircraft would direct the aircraft away from each other, but the opposite had happened.

It said that the pilot of the Virgin plane, which was flying into Heathrow from New York, had assessed the risk of a collision with the Boeing 767 as "high".

At one point, the Virgin plane was just 30 metres (100ft) above the 767, and separated laterally by 1.8 nautical miles - in breach of the legal minimum distance between aircraft.

According to the magazine, the controller had not realised he had mistakenly transposed identifying data on the positions of the two aircraft.

As he tried to force the jets apart, he brought them closer together. During the incident, other controllers gathered around the screen and saw the aircraft converging.

After the incident, Nats put a revised operating procedure in place. The move made controllers mindful of the potential problem, and avoided the recurrrence of a similar difficulty.

Adrian Yalland, a spokesman for Swanwick air traffic control, said that he could not confirm the Computer Weekly account of the incident.

He said the new software was being implemented in addition to the revised procedure, and added: "It's a belt-and-braces approach."

Nats today said that software changes would be made next month following "an extensive design and test programme".

The new software will change the way information is displayed on air traffic controllers' screens to make it easier for them to tell which aircraft each icon relates to, Mr Yalland explained.

[Globaliser]

According to the magazine, the controller had not realised he had mistakenly transposed identifying data on the positions of the two aircraft.

As he tried to force the jets apart, he brought them closer together.If you pardon the expression, this gives one a sense of deja vu.

[Yankee_Doodle_Floppy_Disk]

I wonder how many other ATC systems around the world are capable of confusing the Controller in this way?

I know I can say "been there, done that".
(thankfully without losing separation)

I can tell you that "Skyline" as used in NZ has no function for unjumbling labels.

Having said that, I have seen controllers transpose the data in their head and issue instructions to the wrong aircraft even when the information presented to them was clear.

[DFC]

If the "problem" is the ability to move the lables arround with the posibility of having the lables the wrong way round when aircraft are close then NATS has only to look at it's Scottish ACC system where lables can and are moved around. They can also have a look at Ireland and France and many other places in Europe where the ability to move lables has been in operation for years without incident.

Perhaps the problem is not the position of the label or it's movement but the ability to distinguish the leader line ( the line attaching the lable to the position symbol).

Regards,

DFC

[Avman]

Our European unit had an automatic label deconflicting system on our steam-driven equipment more than 20 years ago! Difficult to believe that a brand new state-of-the-art system was designed without this SAFETY feature!

[eyeinthesky]

The problem was that it was possible to move the TDB (Track Data Block which gives callsign, level, ground speed and other info) around relative to the target symbol and, provided that the TDB remained close to the target symbol, there would be NO leader line (or stick, or pointer or whatever you want to call it) connecting it with the symbol. (There are normally no leader lines anyway.) The line only appeared if you moved the TDB further away.

Most people get used to having the TDBs in a certain position relative to the target, and will automatically know which one goes with which. Once you start moving them about then you need to think about which is which. This can cause confusion, as in this case. I seem to remember (but I may be wrong) that in the incident that was referred to the aircraft had actually crossed flightpaths subsequent to the controller having moved the TDBs (whilst vertically separated) which made the situation doubly confusing, as it was quite feasible for the TDB in one position to be connected to the wrong aircraft.

As I understand it, the new software now makes it impossible to move the TDB even the smallest distance from its default position without generating a leader line back to the target symbol. You might well ask why this wasn't in from the beginning... but there we go.:rolleyes:

[BlackSword]

NATS News at:
http://www.nats.co.uk/news/news_stories/2004_01_20.html

Says:
"Nats responds to media comments on 2002 airprox

A number of newspapers, radio and TV stations report today on an airprox involving a Virgin 747 and a Delta 767, in which track data blocks for the two aircraft were inadvertently swapped on-screen. Today's coverage highlights changes due to be introduced next month to the software at NATS' en-route centre at Swanwick in Hampshire.

It is important to note that this airprox actually took place in November 2002 and was subsequently assessed by the UKAB as category C (no risk of collision). The UKAB report was published in October 2003.

In fact, there have been no risk-bearing incidents at Swanwick since it became operational two years ago. Immediately after this particular incident, an instruction was issued to controllers reminding them of the correct procedure to follow when individual track data blocks are re-positioned, in order to prevent a repeat of these events."

While on P.18 of the UKAB Report:

"http://www.caa.co.uk/docs/423/Analysis of Airprox in UK Airspace Report No 9.pdf"

They classify the level of Risk as B (Safety Not assured).

Ooohh! Errrrr!

[C U JIMMY]

Oh dear, here we go again. Lack of info makes everyone look stupid.
As has rightly been pointed out, there ARE leader lines on the track data blocks if they are positioned far away enough from the radar return.
Following previous problems with misidentification, it is now accepted practice that if the TDBs are to be moved, they must be moved to a point where the leader line can be seen clearly.
The only thing the new software drop does is giv 360 degree movement of the TDBs with leaders appearing at each setting.
The controller in question at Swanwick was not adhering to accepted practice of moving TDBs, and guess what happens!

[eyeinthesky]

Steady on CUJ! The 'controller in question' was using the equipment in a perfectly acceptable manner and in the way it was designed at the time. Unfortunately this led to confusion of the targets and the subsequent incident. Whether the equipment should have been designed in the first place not to allow this to happen is a valid discussion.

The SI/OPNOT or whatever it was that appeared on the sectors telling us not to move TDBs without a leader line was AFTER this incident (the stable door banging shut with the sound of the horse's hooves receding into the distance.. :rolleyes: ..).

Don't pillory the guy who made a mistake with the inference that he was acting incorrectly.