PPRuNe Forums - View Single Post - Virgin Australia Boeing 777 dirty dive at Melbourne 34
Old 25th Oct 2013, 22:53
  #5 (permalink)  
RAD_ALT_ALIVE
 
Join Date: Jan 2001
Location: Australia
Posts: 187
Likes: 0
Received 0 Likes on 0 Posts
Effective threat and error management starts from the time you prepare to leave home/hotel until you complete the parking checklist; it is then constantly re-evaluated and modified to suit the circumstances at the time.

If the crew involved in this event did have interrupted rest (which in my experience is the norm on every longhaul duty) - I fail to see how turbulence enroute can be used as a contributing factor - then an alternative open to them was to require (not request) the RNAV or VOR approach onto 34.

Or if VA management want to enjoy the benefit of uninterrupted rest while curled up next to Mrs VA management, do as EK have done for years and mandate that visual approaches are not permitted whenever there is an instrument approach available to the duty runway (for longhaul ops).

But having said that, the 34 visual approach via SHEED is no biggie if given a few minutes of considered thought. The last time I did it was the first time in about 7 years (some guy living near the final approach to 34 had barricaded himself in his house and was firing shots...thus no IAP to that runway). The old queues were there; MCDU showing 5nm to lose nearly 2200' and visual confirmation at SHEED that we were high.

It also re-ignites the old Airbus v. Boeing thing; team A recommend (and have done so for years) that AP is off for any visual approach, while Boeing don't appear to. Whether it is 'better' than not, I don't know - I do know that it takes away any ambiguity about how the approach will be flown and focuses the mind before the approach even starts. It also means that any botch-up is IMMEDIATELY manageable by a suitable control input. With AP engaged, a departure from the expected takes necessarily longer to correct; identify the excursion, evaluate the reason, determine if it can be saved using the AP, decide it can't, change mindset to that of taking over earlier than planned, recover (which is then far later than it probably should be).
RAD_ALT_ALIVE is offline