Well good for you hero

when you read garbage like this, I felt the need to be a hero

It’s an interesting thread and as I said in another thread it’s up to you the PIC to accept an MEL. It however goes beyond MEL’s it goes to your responsibility as to what you believe to be safe, how fatiguing are the operational procedures in the MEL? No APU in my part of the world would mean a hot cabin very quickly if ground support didn’t have ground ac ready to roll.

Flying a bus, the ole paper techlog days. I always used to flick through the last few pages to see how the old girl had been behaving. Now if my reasoning was correct and my FO agreed, the old girl had 2 computers (yes dumbed down), replaced from 2 different other machines as they were trying to fault find (2 other aircraft). Now I’m no smarty but I figured that in a machine that had 3 computers and had 2 suss ones from other machines then….. Yeah nah I ain’t no test pilot and called the CP.

His first thought was nah, engineering wouldn’t do that, on confirmation I had his full support. Less than a 30 min delay as a spare new computer was plugged in so now we only had one on ‘test’.

Airlines will do anything to save a buck, it’s up to the PIC to make sure they accept an aircraft. As for multiple MEL’s, I was always lucky enough to have a pretty good fleet to fly with generally great support. However as above things still slipped through the cracks.

Now I know others would have accepted the aircraft and flown but not me.

Flew with an APU inoperative under an MEL yesterday. It was a little warmer than usual prior to start and my uniform a little more moist than I’d like to admit. Alas, the aircraft didn’t fall out of the sky.

Perhaps Geoff Thomas would care to comment..

If you have a valid reason, yes. Refusing to use the legal tools at your disposal (MEL) without a valid and reasonable reason won’t last very long.

An age old issue and you are all correct. However you should be under no dillusion that right or wrong if there is a recurring incidence of it and you find yourself locking horns with someone further up the food chain, you can expect an early retirement eventually.

obviously

Moved from D&G. This topic should get a better airing in Tech Log, perhaps ?

I've been involved in various aspects of MEL development and the problem is that the folks around the table arguing this way and that can only dream up so many situations of risk. We might opine that the MEL is reasonably sound and should get us along the way in MOST situations and circumstances. No one of rational thought would argue that every MEL is ironclad through and through. Engineering risk assessment doesn't go that far.

The PIC's role is to accept the initial work for what it is worth but then consider the "how about TODAY question". If he/she can't come up with a feasible problem which might cause heartache on today's flying, perhaps it is a reasonable call to say, "fine, we'll take it". On the other hand, it might just be that today's combination of night, IMC, weather, other snags on the aircraft, etc., etc., could cause him or her to suck in the breath and wonder "what about if we run into a problem along the lines of XYZ" ? Maybe we gracefully decline on this occasion ?

One problem which we have all seen is where the line pilot declines the MEL activation and then, Johnny Management comes to the rescue five minutes later with a hearty "I'll take it" .... no system is perfect, we can only try to do our best to achieve the gameplan goal.

Had a cracker a few months ago,

APU OUT
1 PACK OUT
1 REVERSOR OUT
AUTOBRAKE U/S
AUTO SPEEDBRAKE OUT
ENGINE ANTI ICE OUT L/H ENGINE
ANTISKID OUT
3 CDL’s

Let’s just say it turned into a ferry flight instead of an RPT service lol.

That’s a good example. I’m normally quite happy with items that just leave you with a bit less redundancy but when you get multiple defects that considerably increase workload and/or reduce performance then it’s time to take a step back. Given the number of possible items you can carry, you don’t need to have many randomly picked from the list before it becomes likely that no-one has operated with that combination before, which should give pause for thought.

The people who author the MEL/DDG are pretty good at it but they can only take into account a certain amount of extant or subsequent failure, probably fairly obvious ones. Stack ‘em up and you’re soon into test pilot territory, like QF32.

I think this is a self limiting problem! I.e. how long till you divert because you could not fly through a cloud layer on approach due to the missing ant-ice? Or blocked a runway due to shredded tires (anti-skid)?



Apart from these extreme horror stories, the question of the OP remains. Do recent events merit a change in the APU inop MEL-procedure?

Do recent events merit a change in the APU inop MEL-procedure?

Minor point of order. The MMEL is the "official" generic document usually generated by the OEM and approved by the Regulator. Individual operators then start from the MMEL to develop their own, specific MEL which, subsequently, will be approved by the Regulator or a delegate.

Mine has three main generators, two backups and a RAT: lost a main gen the other night, checklist said start the APU and shortly after the ovens and IFE were back on line; if the APU had failed to start we still had 3 generators so no panic, just a bit of load shedding.

If you had just the two gens, U/S APU, no RAT and one of them failed, it’s likely to be land at nearest suitable due to the next step being battery power, but this is all taken care of in the MEL when dispatching (likely both gens required).

Would a functioning APU have helped much in Korea recently? Their problem was more to do with failing engines and the aircraft position; chances were they still had some hydraulics and standby power. To directly answer the question, no, I don’t think APU serviceability needs to be taken into account any more than it is now, as it’s not guaranteed to start anyway. I would be more likely to question the dispatch of an aircraft if it was hot at destination and ground air was unreliable/unavailable...