PPRuNe Forums - View Single Post - AF 447 Thread No. 7
View Single Post
Old 16th Nov 2011, 13:11
  #298 (permalink)  
infrequentflyer789
 
Join Date: Jan 2008
Location: uk
Posts: 857
Likes: 0
Received 0 Likes on 0 Posts
Post

Originally Posted by airtren
It was implied that testing is done, and it is proportional in all aspects to the type of system, and the type of manufacturer. Please don't make assumptions what I know or don't, and let's keep things at their real scale and proportions. I think it is expected that Airbus is not bellow - actually it could be very well above - the level that is considered norm in such type of critical systems, and the testing is sophisticated, with extensive automation/simulation.
I'd agree with that, but the tak might not be as simple as presented.

We are talking about taking a single protection active in one law/mode and making it available in another mode. In the other mode that protection is part of a set, and the algortihms and code may well be interdependent, so you have to first split out the logic for that one protection and that might not be simple. Setting up the testing etc. won't be as simple either, for the same reason.

Further, it's entirely possible that the air data you need for the protection is simply not available at the flight control computers (prim or sec) in the event of airdata failure. I'm basing that on two things - the non-switch to abnormal-attitute law in 447 (which should have tripped on AOA, but didn't because of triple AD failure) and the reports that the BUSS option requires new airdata units in order to route raw AOA data around the ADIRU. Even if you could base your new code off the BUSS option, that still makes it a non-trivial hardware change rather than just a software patch, and you've also probably got to get an additional input ("raw" AOA) into the flight computers - maybe more hardware change and definitely much more testing.


However, I think there may be an even bigger problem that is much more fundamental. Looking across the civilian FBW implementations, there is a clear and consistent decision that protections/limits based on airdata are dropped when airdata is not valid/trusted. Either that is an independent engineering decision across teams/types and mfrs (yes, it's the same on B), or it's a regulatory / certification decision.

You need to overturn that decision to put trim protections into Alt2.

Bear in mind that if/when you do, a line has been crossed. Currently with UAS or other airdata failure, a good crew that can
a) work out which instruments they can trust
b) fly the plane within the safe envelope based on (a)
will survive. Throw in protections based on partial/incomplete/known-bad airdata and sooner or later you will kill a good crew that's doing the right thing. [There is still a chance of that in normal law, but it's much lower and much easier to quantify and try to design out. You couldn't even simulate all the failure modes for the input data for the bad airdata case].

So, who do you want to kill ? - because that is what it boils down to. It's normally the engineers faced with the dilema, maybe it should be answered by the pilots ?
infrequentflyer789 is offline