PPRuNe Forums

PPRuNe Forums (https://www.pprune.org/)
-   Australia, New Zealand & the Pacific (https://www.pprune.org/australia-new-zealand-pacific-90/)
-   -   Sydney Airport problems again (https://www.pprune.org/australia-new-zealand-pacific/599935-sydney-airport-problems-again.html)

QSK? 25th Sep 2017 04:23

I think what Advance is trying to convey here is that Airservices' SMS procedures should ensure that any single ATC system component failure should not result in the need for implementation of any reduction in airspace utilisation or capacity to maintain aviation safety. The fact that Airservices had to resort to implementing limits on traffic handling capacity indicates that their SMS approach had failed and that, in order, to continue to maintain adequate safety, traffic handling limits had to be imposed as a last resort. The question Advance is really asking is what was the level of safety available to in-flight pilots between the time the failure first occurred and the time that the traffic handling limits started to become effective.

Advance 25th Sep 2017 04:25

NO mikethepomme. Rather the reverse. As I pointed out early in the chain, the whole point of having radar is to increase safe capacity beyond that available without radar. But in doing so it must be recognised that any failure may leave an unsafe, overcapacity situation. The safety case is intended to examine failure modes (FMEA) and ensure there are systemic redunancies and excess capacities so that a failure does not necessitate traffic reduction precisely because in the time it takes to actually reduce traffic there is an excess beyond safe capacity.

The FAA actually carried out an extensive study on the subject before they introduced ARTS I - what, back in the '50's.

The latest info in the Sydney newspapers (they must be right??) is that the system failed to "uncombine" from night mode when called upon to do so, leaving but one console working.

A software change is being blamed. So clearly the safety case justifying the change, if it was prepared at all, did not address the failure mode that eventuated.

Sure, systems fail but safety is about ensuing the failure does not increase risk.

mikethepomme 25th Sep 2017 04:39

Well if the case was an inability to decombine... then there should be no increased risk... as one controller would have been able to handle the workload on one console before the problem. Traffic would then get metered to make sure he could handle it during the problem.

Stopping departures, holding aircraft out etc.

Capn Rex Havoc 25th Sep 2017 05:01

YSSY is really very ASSY.

morno 25th Sep 2017 09:04

Maybe they should have tried airplane mode instead

Ivasrus 25th Sep 2017 10:45

Advance, TAAATS is designed to fallback to 'degraded mode' where the existing radar picture doesn't really change that much, but the controllers lose much of the system automation. This is why one of the the first actions in the quick reference guide is to "stop departures". Sorting out existing airborne traffic, even at maximum capacity, is safely manageable. The system in 'degraded mode' isn't able to easily cope with new flights hence the severe restrictions placed on departing flights as soon as the failure becomes apparent. Consider this akin to "land at closest suitable airport". Hope this helps.

As far as causal factors I dare say that will take some time.

underfire 25th Sep 2017 12:06


Managed to correct the typo in the post but not in the List of Aust.NZ etc.
How is that done?
Go to edit your post...at the bottom, click where it says go advanced. (the other GA!)

You can edit the title there.

RodH 25th Sep 2017 21:00

It does change it in the edit function but it still shows up as ASSY in the
Australia, New Zealand & the Pacific List of posts. It is corrected in the post itself but not in the master list.

underfire 27th Sep 2017 17:54

Power failure in SYD was the cause of it all.

Brilliant!

sierra5913 28th Sep 2017 03:11


Originally Posted by underfire (Post 9905965)
Power failure in SYD was the cause of it all.

Brilliant!

Those damn renewables...

underfire 28th Sep 2017 13:49

solar powered and shuts off at night.

Nick_F 7th Oct 2017 15:01

I don't think Sydney is as bad as Brisbane. Or even Melbourne for that matter.

Duane 15th Oct 2017 09:41


Originally Posted by Advance (Post 9903011)
NO mikethepomme. Rather the reverse. As I pointed out early in the chain, the whole point of having radar is to increase safe capacity beyond that available without radar. But in doing so it must be recognised that any failure may leave an unsafe, overcapacity situation. The safety case is intended to examine failure modes (FMEA) and ensure there are systemic redunancies and excess capacities so that a failure does not necessitate traffic reduction precisely because in the time it takes to actually reduce traffic there is an excess beyond safe capacity.

The FAA actually carried out an extensive study on the subject before they introduced ARTS I - what, back in the '50's.

The latest info in the Sydney newspapers (they must be right??) is that the system failed to "uncombine" from night mode when called upon to do so, leaving but one console working.

A software change is being blamed. So clearly the safety case justifying the change, if it was prepared at all, did not address the failure mode that eventuated.

Sure, systems fail but safety is about ensuing the failure does not increase risk.

Advance, you dont have a clue what you are talking about, and obviously have no familiarity with ATC in Australia, in particular Eurocat, perhaps keep your mouth shut lest you make yourself look like a fool.

The issue was of the 2 LAN connectors, when one fails the other takes over, in this case, path A didnt fail gracefully, it kept sending messages, so many in fact that the Sydney partition became overloaded, then the melbourne system, then the brisbane system. It was a very unusual failure, one that hasnt happened before anywhere in the world that has run Eurocat.

What this meant was that positions couldnt be moved split or whatever; resulting in curfew setup continuing beyond curfew period.

Safety was never effected.
Radar was never effected.
The ability to process more than say 10 arrivals an hour was impacted.

Literally zero of your suppositions in this thread that you have raised are even close to correct.

josephfeatherweight 15th Oct 2017 09:44

Best you learn to spell "affected" correctly:

lest you make yourself look like a fool

Duane 15th Oct 2017 09:49

Well at least I am not speculating and talking out my ass pretending to know ****.

I think that what he is trying to say is, when something fails, ATC should be able to process the exact same amount of traffic as if it hadnt failed. You know like when planes lose an engine they fly exactly the same profile right?

If path 1 (of 2) fails and you are now operating on your backup path, you dont use it the same as if you had redundancy, that is crazy, you dont know why it failed, and you are just going to assume its ok to keep using at max capacity, what if the same failure occurs and you are at max rate.. such a stupid position to maintain. The SMS is to reduce traffic levels until the system returns to normal so you can return to normal levels of traffic. I dont know how you have it in your head that the SMS failed. The SMS that was implemented worked, people got delayed, everyone landed safely who could get a slot, internationals got prioritized short of inconveniencing some people the failure was handled well.

The radar wasnt effected, btw SY gets a mosaic of about 7 radar feeds, but if the TAR gets lost or degraded things will get slow down.

Slowing the rate is a perfectly logical and safe way to implement the SMS, if you are serious that you think that regardless of fault the rate shouldnt change, you are being entirely unrealistic. Planes dont have a back up engine they can whack on the wing when one fails, you cant expect to operate like normal when dealing with a failure. If you need this explained to you any further Advance, you are just being obtuse.

rjtjrt 15th Oct 2017 10:13


Originally Posted by josephfeatherweight (Post 9925623)
Best you learn to spell "affected" correctly:

He did spell "effected" correctly.
Perhaps you mean to correct his grammatical use of effected vs affected, not a spelling error.

das Uber Soldat 15th Oct 2017 13:23


Originally Posted by josephfeatherweight
Best you learn to spell "affected" correctly:


Originally Posted by rjtjrt (Post 9925649)
He did spell "effected" correctly.
Perhaps you mean to correct his grammatical use of effected vs affected, not a spelling error.

This boys and girls, is why I don't hang out with pilots.

IsDon 15th Oct 2017 22:15


Originally Posted by das Uber Soldat (Post 9925812)
This boys and girls, is why I don't hang out with pilots.

And yet here you are. :confused:

QSK? 15th Oct 2017 23:00

Oh Dear
 
Duane

Was the aggressive tone of your emails really necessary? This forum is successful because, generally, it operates on mutual respect.

If Advance is who I think he is, then you might be surprised as to how much he knows about ATC and Eurocat.

Give respect and you will then receive respect. If you can't do that, then get off these fora

Duane 16th Oct 2017 04:51


Originally Posted by QSK? (Post 9926224)
Duane

Was the aggressive tone of your emails really necessary? This forum is successful because, generally, it operates on mutual respect.

If Advance is who I think he is, then you might be surprised as to how much he knows about ATC and Eurocat.

Give respect and you will then receive respect. If you can't do that, then get off these fora

If he did have any clue about how Eurocat works or about how ATC works in Australia, he would not have made the speculative jumps he did, nor insist implementation of a SMS means 100% output capacity. I am sorry but as someone who works the system; to have people with little to no knowledge of what we do come here and put us on blast every couple of weeks gets old, and he is quite clearly in this case, talking about something he knows nothing about.


All times are GMT. The time now is 06:24.


Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.