Originally Posted by
airtren
I read your "may" as your making a cautious assumption, which is always welcome at the outset. A closer perspective can clarify if the more distant perspective caution is justified.
You're right, but it's also a general statement of the need to be cautious about what is or is not "simple" in software without detailed knowledge. A fair few years in software development has taught me that it's very easy for someone to believe they know enough about the internals of a system to assess the impact of a change request, when in fact they don't. Dependencies can be very subtle. Often the CR will eventually (sometimes only after the test start failing or the user bug reports start landing) hit the desk of the person that
does understand the impact and result in an expletive laden exclamation about how that change could obviously never be done without a major redesign...
Unless you've actually worked with and modified (not just read) the actual code, I would always advise that caution. Sometimes I might even follow that advice myself
[I have, I admit, been on both sides of this issue...].
With the risk of repeating the considerations mentioned by AlphaZuluRomeo, with my own closer perspective and words:
Be interested if you know whether or not there would be a change required for getting AOA into the FCPC around the ADIRU in the event of ADIRU going "failed".
We have the STALL condition being announced loudly
Stall
warning.
at High Altitude Stall Approach, or Stall is to bring the ND, which implies the strong recommendation of NO Manual Trimming NU during such conditions!
And therein lies the dillema -
warning vs actual
conditions. Maybe I didn't expalin well.
If the 'bus flight control is in a mode where it is confident that stall
condition is anywhere near, it will take action to prevent it (over and above trim limits). Normal law.
If it has lost confidence (e.g. airdata fail) about its
condition but has indication that it
might be stalling, it will
warn the real pilots, but not take overriding action. The pilots can then use actual intelligence (of which the machine has none) to assess the warning and the condition of the a/c and take action. Worth looking at Perpignan report for another example of the difference (dual aoa failure, outlier aoa not trusted for protection but used for warning).
In this case, 447, the warning was actually right, and the pilots assessment fatally wrong.
Change it so the FCC will
act and "
protect" in the warning scenario
based on known-bad data, then you might save 447. At the same time, you risk the
warning being
wrong (due to bad data), the pilot assessment and actions being
correct, and the a/c "
protecting" them into the ground...
I think the risks either way are going to be very very difficult to quantify which is why this is a tough call.