Jump to content
Sign in to follow this  
tantonovich

Question re: DC BUS 1 Failure

Recommended Posts

So I fly with random failures and had a doozy today:  had my AP disengage during cruise, lost Yaw Damper, Mach Trim, Speed Trim, Pressurization AUTO FAIL, Captain's F/D fail, ANTI-SKID INOP all at once!!  I pretty quickly discovered that I could re-engage AP on CMD B and got the aircraft controlled that way, then went to work troubleshooting.  I figured this was all due to a single common failure, but rather than break out the electrical schematics I figured the QRH would lead me in the right direction if I started checking out the individual failures.  That didn't happen... 

 

So after I got nowhere that way (except fixing the pressurization by switching to ALTN), I checked out the schematics and traced this down to a loss of the entire DC BUS 1 (verified by cheating and looking in the FMC failures page).  What I'm wondering is this:  Is it normal that the QRH/FCOM doesn't have any procedures to deal with the loss of an entire bus?  I mean, the information is there, but it's quite scattered.  Since there are so many systems attached to the buses, it seems to me that Boeing would have some kind of Deferred Checklist for a failed bus so that all of the little caveats were able to be noted in one place.  

 

Since this is not available in the docs, a pilot has to first find the list of all systems attached to the failed bus, then individually look them up in the QRH to see if there are deferred items to take into consideration before landing.  For instance, since I'm ANTI-SKID INOP, I need to not arm Speedbrakes before landing.  I will also not have thrust reversers on engine 1 (I think?).  

 

Anyways, just asking out of curiousity while I'm waiting for this flight to finish...

 

Tom Antonovich

PANC

Share this post


Link to post
Share on other sites

I understand what you are saying, but i think its best for the pilot to fault find each failed item that shows up so he/she understands what item has failed and what to do.

 

Maybe someone will have a better answer than me! Ever way you still have to go through each fault and understand it clearly so you can then make a correct course of action.


Vernon Howells

Share this post


Link to post
Share on other sites

I understand what you are saying, but i think its best for the pilot to fault find each failed item that shows up so he/she understands what item has failed and what to do.

 

Maybe someone will have a better answer than me! Ever way you still have to go through each fault and understand it clearly so you can then make a correct course of action.

I agree, I think going through each item gives a thorough understanding of each individual issue.  Plus, I would imagine that IRW the crew would write down all of the deferred items as they went through the items, then make sure they hit all of them before descent/approach/landing as appropriate.  

I guess I'm just surprised that, since a bus failure affects so many systems, there isn't either a certified NNC or anything like that.  Keep in mind I'm not complaining, reporting a bug, or anything like that.  Just raising this because it's an interesting issue and it makes me wonder how it would be handled IRW.

 

I found an incident from 1994 of almost the exact same issue and the NTSB remarked on the absence of such a procedure, pretty interesting reading!  I would be very interested to hear from a real-world ATP about this.  I'm sure it's an extremely rare possibility, but given the amount of systems connected to these buses I would be scared to death of losing a bus if I were a 737NG driver.  http://www.fss.aero/accident-reports/dvdfiles/US/1994-04-26-US.pdf

Share this post


Link to post
Share on other sites

The QRH is there to deal with failure indications and consequences, not necessarily to identify the cause of the problem. That's up to the crew, and why they go to ground school. The problem the NTSB raised is that there is nothing to lead the pilot towards a bus failure conclusion, but how can there be without failure monitoring on each bus. It's up to the crew to relate any other failure indications to a common cause. The 737 has no EICAS to assist this.

 

In contrast, the Airbus ECAM can overload the crew with consequential actions to complete. As shown by the Qantas A380 engine incident. Boeing EICAS works more on a "need to know" basis.

 

As for not arming the speedbrake with antiskid INOP, surely no harm would be done by arming it. The speedbrake wouldn't auto deploy, but you should notice that. If the system had detected a problem with speedbrake arming then the SPEED BRAKE DO NOT ARM light would illuminate as soon as you took the lever out of the down detent.


ki9cAAb.jpg

Share this post


Link to post
Share on other sites

That is a very good point, Kevin: in real life a significant part of any type rating is systems knowledge.

 

 

 


As for not arming the speedbrake with antiskid INOP, surely no harm would be done by arming it. The speedbrake wouldn't auto deploy, but you should notice that.

 

I would imagine the rationale is that if there is a requirement to deploy the speedbrake manually, not arming it serves as an extra reminder that auto-deployment will not occur. This would also retain commonality with other non-normal situations where manual speedbrake deployment is required, and in the event that there is only a partial or intermittent failure, will prevent the speedbrake from deploying automatically when it is not expected or desired (I don't know how violently the speedbrake handle moves on deployment, but apart from anything else if PM's fingers are near the lever when it auto-deploys unexpectedly there could be a H&S issue.

 

Is it purely because of the antiskid inop that the speedbrake must be deployed manually, or is it because of interplay with other systems or flight control issues? I know in certain failure modes on the Jumbo, there may be either no staged deployment of the ground spoilers and/or pitch authority may be degraded, which may result in an unexpected/difficult to control pitch up moment. In situations where this would be an issue the instruction is to wait until the nosewheel is on the ground and only then deplay the spoilers manually and smoothly. (The gotcha is that you must also do this before applying reverse thrust, because, of course, selecting reverse thrust automatically deploys the speedbrakes).

Share this post


Link to post
Share on other sites

KevinH, I think you may have misunderstood, neither myself nor the NTSB report talked about a need for instrumentation in >identifying< the problem; as you are correct that there's really no way to do that with an entire bus failure. Training and systems knowledge are necessary to recognize this type of failure and confirm that's what you have experienced if it happens.

 

What I'm getting at is the part of the report that talks about there being no workaround procedures. Sure, pilots can figure it all out themselves, however isn't the point of documented checklists and procedures to eliminate human error? What I'm saying is that it seems strange there's no documentation for what to do AFTER you've identified the bus failure.

 

Another odd thing regarding the speedbrakes: I followed the NNP and deployed manually, but they were INOP anyways. Go figure, right? Haha!

Share this post


Link to post
Share on other sites

KevinH, I think you may have misunderstood, neither myself nor the NTSB report talked about a need for instrumentation in >identifying< the problem; as you are correct that there's really no way to do that with an entire bus failure. Training and systems knowledge are necessary to recognize this type of failure and confirm that's what you have experienced if it happens.

 

What I'm getting at is the part of the report that talks about there being no workaround procedures. Sure, pilots can figure it all out themselves, however isn't the point of documented checklists and procedures to eliminate human error? What I'm saying is that it seems strange there's no documentation for what to do AFTER you've identified the bus failure.

 

Another odd thing regarding the speedbrakes: I followed the NNP and deployed manually, but they were INOP anyways. Go figure, right? Haha!

I don't think I've misunderstood the report. The NTSB didn't say there should be a procedure to identify bus failures, it just remarked that there wasn't. The Boeing representative explained why. There is no corrective action available even if you do identify this bus failure. All you can do is run the checklists for the failed items and secure those correctly.

 

I think you may be expecting the checklist to tell you what to do in all circumstances. That isn't the Boeing philosophy, which is more about making sure the important safety items are covered and checked. Doing things afterwards based on assumptions is an airmanship judgement call and beyond the realm of checklists. Giving a two man crew even more, possibly redundant, checklists to run which might not make much material improvement probably isn't a good idea.

 

You landed your NGX safely. That Aloha 737-200 crew did the same. All that was missing was a diagnosis to the cause of the problem. You don't need the QRH to contain the means to do that. That's what the FCOM is for.


ki9cAAb.jpg

Share this post


Link to post
Share on other sites

 

 


I checked out the schematics and traced this down to a loss of the entire DC BUS 1

 

Which schematics did you use to track that down?


Matt Cee

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...