Go Back  PPRuNe Forums > Flight Deck Forums > Tech Log
Reload this Page >

AF 447 Thread No. 7

Tech Log The very best in practical technical discussion on the web

AF 447 Thread No. 7

Old 14th Nov 2011, 00:29
  #201 (permalink)  
 
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by AlphaZuluRomeo
For the record, and despite I doubt it would have changed the outcome in the light of the crew actions, I see two of them:
OK, that's cool - and that was all I was asking for. I'm puzzled as to why other posters regard it as though it's like pulling teeth and expect me to jump through hoops for them before I get a reasonable answer. Let's have a look!

1/ the non-inhibition of the nose-up autotrim when stall warning is active
2/ the inhibition of the stall warning under 60kt IAS (even if I understand the logic behind the inhibition, I still think it may be worth reworking that bit of logic)
So first of all, looking at these in a cursory manner, these are not "logical errors" in terms of software engineering - the term has a very specific meaning which is whereby programming instructions that are syntactically correct nevertheless produce erroneous return data. What you're describing here is a situation where a system operating in the field has produced results that highlight potential issues going right back to the specification (or indeed a set of circumstances that the original specification did not or could not take into account) - the result of which is what us nerds refer to as a "change request".

Now I've got that rather dull bit of nitpicking out of the way, let's dig in.

1. Limiting the autotrim in response to a stall warning sounds good in theory, but you're going to have two major problems right off the bat. The first is quite simple, and that is "what happens if the stall warning is false?". I can foresee a couple of situations off the top of my head where that could be more dangerous than letting the trim run. The second is a bit more esoteric and complex, and indeed can apply to all the things you're talking about, and that is the increase in complexity such a change will add to the system as a whole. Determining the knock-on effect that change would have is a very involved process and the logic paths would have to be scrutinised at a very in-depth level, and of course you run afoul of the old engineering maxim that adding complexity is increasing the number of potential points of failure. That said, it looks like the A320 has a hard nose-up limit on the autotrim in Alternate of 3 degrees, while the A330 does not. I'd be interested to know what they discovered inbetween development of the two airliners that led to that change. I think that a hard limit would probably be a more effective solution than checking against Stall Warning status (which is after all in a completely different subsystem and may or may not be valid).

2. I wouldn't be surprised if most airliner designs of a mid-80's vintage or later have similar logic. Determining whether a stall warning is valid or not has been a tough nut to crack for a long time, and in an overwhelming majority of cases, the limits set probably make good sense - I mean this is the only case where it has been perceived as an issue and in order to make it one the aircraft was taken further out of the flight envelope than any test pilot would dare attempt. On paper it looks sensible, because Stall is a function of AoA, and the limit of the AoA vanes' effectiveness as reported by the supplier is <60kts. I saw talk of using a WoW switch earlier, and I don't think that the designers would assume that if the computed speed is less than 60kts then the aircraft must be on the ground, given how in-depth they went and how many permutations they went through to arrive at the spec they did. In their shoes I'd be thinking "if we know that the data is going to be unreliable past this point, then it's probably best discarded". Unfortunately they didn't bet on the set of circumstances that caused AF447 (specifically "what if an aircraft was held in a stall to the point where that limit is reached?"), and even those who have no particular love for Airbus have to admit it's an edge case to end all edge cases. I have no clue how easy or difficult it would be to latch the current stall warning status when that limit is reached, and I foresee complexity arising from what to do once a recovery has been effected (namely "We've latched stall warning because we can't trust the data, so at what point can we start trusting it again?").

And perhaps a 3rd and 4th, but as I don't know the logic behind I'm not qualified to fully comment:
3/ the V/S switching source from air data to inertial (and back); it occured in AF447 and its consequence was a non-readable/unreliable/unrealistic displayed (air data sourced) V/S, while at the same time a reliable/realistic V/S value (aka inertial sourced V/S) was available (for the system).
4/ the non-inhibition of the F/Ds (by the system) when an UAS situation is detected: why? A/P & A/THR may (and have) been dropped, why not the F/Ds as they may give unreliable directions in such a situation?
These are definitely trickier as they depend on a given reading of the DFDR data in Interim #3.

3. Are you sure that the V/S trace indicates mode-switching from air data to inertial and back? I was told that the extreme variations towards the end of the trace indicate the static ports being fouled by the airflow induced by the stall, and it is not until the computed airspeed is in the low 100kts area (by which point the stall is well-established) that the readings start to look wrong

4. For starters, I'm not sure how to read the FD trace accurately, but they are inhibited when airspeed data is lost (as you'd expect them to be) - those spikes during the period of actual UAS indication might indicate attempts to re-engage them manually, but I have to defer to more knowledgable folks there. The FDs come back on (as they are designed to) when the airspeed data returned and then switch off again as the aircraft slows to the point where presumably the stalled air is playing merry havoc with the pitot/static and AoA sensors

In these cases, the situation the aircraft found itself in was so extreme that I wouldn't know where to start in terms of getting reliable and accurate data. I wonder what difference having the BUSS might have made?

Last edited by DozyWannabe; 14th Nov 2011 at 02:07.
DozyWannabe is offline  
Old 14th Nov 2011, 00:43
  #202 (permalink)  
 
Join Date: Aug 2009
Location: Germany
Age: 67
Posts: 1,777
Likes: 0
Received 0 Likes on 0 Posts
Cool

Hi,

AlphaZuluRomeo
But what do you make of that statement? Are you advocating that, because "automation" (which part(s) ? flight controls? A/P? A/THR? all of those? more?) uses air data, and air data is not 100% reliable, the industry should renounce "automation"??
Air data is 100% reliable .. provided that air data is gathered by a reliable captor
So far ... it's proofed that under certain conditions (who are common for a A330 or any modern airliner) those captors are not reliable and can send false or not information at all to the automatic system
So the industry must not renounce "automation" .. provided they correct the weaknesses
Apparently nothing positive was made for correct the problem ... but paper work and modified training
It's agravated by the fact that this problem is know from ages ..
The original problem stay hidden rear the corner

Clandestino
Quote:
Originally Posted by jcjeant
he was no more a pilot .. he forget he was a pilot ..

Since you say so, is this applicable to the case we're discussing, too?
I read in the BEA report N°3 (CVR extracts) that the pilots are telling .. they don't understand and they have no more indications
Or .. the BEA affirm that all was functioning normally (less airspeed indications) and the plane was airworthy
So how you call people facing instrument panel working in a plane working and who are telling they understand nothing ?

Last edited by jcjeant; 14th Nov 2011 at 00:56.
jcjeant is offline  
Old 14th Nov 2011, 00:49
  #203 (permalink)  
 
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by airtren
So, you've echoed repeatedly publicly an idiotic statement sent to you via a PM - I have no idea who the "same person" you're mentioning is - and offer a conditional apology?
It didn't seem idiotic at the time, it wasn't just one person passing that information along and I had (and still have) no reason to believe that they would deliberately misinform me, in fact it's likely someone misinformed them.

The Moderator deleted your first post, after you refused to do it at my respectful request, but then you keep repeating it, as soon as I start posting, as a tool of intimidation.
In fact the moderators deleted a whole swath of posts from that period and at no point was I contacted directly by the moderating team saying I had erred or otherwise - you make it sound like I was singled out for admonishment when it was not the case.

You can start with your own computer expertise - as an advertised software engineer, you should do a lot better - as you seem to have no clue on detecting network applications impersonations, continue with your interaction with the Moderator, continue with a better management of your tactical arsenal devices and finally improving your apology section.
Aside from the fact that I participate in these forums as a way of taking my brain off the software development track for short periods of time, I have no access to the IP logs of this forum and therefore no way (or at least no *legal* way) of telling - other than building relationships with knowledgeable and trustworthy posters - people are who they say they are. The heads-up came from more than one person, at least one of them had proven trustworthy in the past, and it happened during a period of a lot of people who had previously been curiously silent sticking their oar in, and at least one user going under two different handles (i.e. sockpuppeting). As I said before, none of the moderating team has interacted directly with me either privately or publicly, so I don't know what you're getting at.

If the information was incorrect then, as I said, you have my apology. Other than that I don't know what more I can say or do at this point.
DozyWannabe is offline  
Old 14th Nov 2011, 01:25
  #204 (permalink)  
 
Join Date: Aug 2011
Location: Near LHR
Age: 57
Posts: 37
Likes: 0
Received 0 Likes on 0 Posts
@Old Carthusian:

Hi,

I don't know why you're addressing a reply to me about your flying background - I didn't ask any question about it

My earlier replies to you were just trying to help correct the mis-description of what a nose-up AI indication means (or rather doesn't necessarily mean). That interpretation is especially relevant in the case of AF447 when stalled, of course. I thought I would try explaining it slightly differently, to see if that helped, since you were saying the same thing to multiple other members who were also trying to explain the fallacy of your statement as it was written (which you later explained was not what you really meant).

Someone else suggested the discussion about general AI interpretation was off-topic in this thread, and I agreed to stop. That's all

While I don't agree with all your comments below, since you've kindly explained some of your thoughts, here are some of my own...

Originally Posted by Old Carthusian
The implications are very disturbing - almost as if there is a disease that can infect any airline.
I agree - since HF seems to be a significant contributor to this accident, and humans are involved as flight crew on other airlines, personally I have not concluded that only Air France CRM training / assumptions of hand-flying training requirements / etc. [add other human factors as needed] are likely to have been lacking at that time.

In fact I remember another pilot here (not AF as far as I know) who said a while back, that high-altitude manual handling training and high-altitude UAS training had been introduced on his airline after AF447. That suggests such training was also lacking on that airline too, prior to this accident - so AF was not alone, it seems.

Originally Posted by Old Carthusian
Arguments about automation and greater computing taking away flying skills may have some bearing but not really.
Based on my reading, I politely disagree about the "not really". The paper by Dr Lisanne Bainbridge called "Ironies of Automation" seems extremely relevant here (I first found that paper a while ago, via a link in another accident report - NTSB, I think - this is not the first time that AP handed over to pilot, who seemed unable to grasp the situation from a "cold start"). This isn't a criticism of pilots - it's a limitation of humans IMHO.

Also the concept of "startle factor" (when automation unexpectedly hands-over to the pilot) was shown in an AF training slide in an earlier segment of this thread, so this issue is known. The man-machine interface (and humans not being well-suited to a monitoring-only situation, which is more & more the case with modern flying) makes me very interested in the effects of increased automation, and its part in accidents like this.

Originally Posted by Old Carthusian
However, the yoke would not have saved the aircraft in this incident because the issue is cultural not mechanical.
Perhaps, perhaps not. I don't believe anyone can say that yokes "would not" have helped (nor that they "would have" helped) - we simply don't know, since we can't re-run this scenario with this crew (unless you have a time machine to re-run that flight in an A332 fitted with (preferably coupled/back-driven) yokes ). I've seen enough arguments from members here (some quite assertive!) with merit on both sides, to see that there are benefits (and deficiencies) to both systems.

LOC accidents with yoke-equipped aircraft as previously mentioned by other members, show that they are not a panacea. However I don't see how anyone could rule-out in this case, the possibility of the PNF being more assertive (e.g. perhaps taking control earlier) if he was more aware (by having the yoke pressed to his body) of the PF's extreme nose-up inputs. We can't ask him, so we'll never know whether that knowledge might have changed his behaviour

I will just point out that the CVR conversation at 2h 13m 40s seems particularly important regarding the [lack of] awareness of the other crew to the PF's inputs - especially since (according to the released CVR transcript), the PF was not verbally communicating his decisions & inputs most of the time. Would a yoke have improved this PNF + Capn awareness enough (and quickly enough) to change the outcome? I don't know, and perhaps only if the PNF or Capn caused a change in PF inputs (or one of them took control) earlier than this point in the sequence - but I doubt that a yoke would have made the PNF & Capn's awareness of the PF's inputs worse.

The HF part of the final report will make interesting reading, IMHO.
Diagnostic is offline  
Old 14th Nov 2011, 02:09
  #205 (permalink)  
 
Join Date: Jul 2009
Location: DFW
Age: 61
Posts: 221
Likes: 0
Received 0 Likes on 0 Posts
Regarding my mentioned experience where a A319 did not respond to a nose down SS input: for the brief moment I was in an updraft, the nose did not follow the input - once I flew out of the updraft the nose came down and we continued as if nothing had happened......... Knowing that pitch is load factor demand, and being in a updraft/downdraft/updraft/downdraft situation, and considering that the nose came down as soon as I passed the building cumulus, and considering that the Bus behaved normally the rest of the flight, I chalked it up to being in an Airbus. To me, it was no different than waiting for the MCDU to finish "updating" the page. Airbus pilots will know what I'm talking about.

Sorry Clandestino, but you're being overly dramatic. No report was made because none was necessary.
TTex600 is offline  
Old 14th Nov 2011, 02:14
  #206 (permalink)  
 
Join Date: Jul 2011
Location: Northern Hemisphere
Posts: 195
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by DozyWannabe
OK, that's cool - and that was all I was asking for. I'm puzzled as to why other posters regard it as though it's like pulling teeth and expect me to jump through hoops for them before I get a reasonable answer. Let's have a look!
You are talking about pooling teeth?

I have asked you a clarification on your mentioning of the Airbus design problem with the pitot tubes, and you have not provided that yet. That's not even a new question like you've asked.

You get back exactly what you do, not answering the questions in your queue in a timely fashion......

But actually, I am on this, with my Smoke Detector ON so....

So first of all, looking at these in a cursory manner, these are not "logical errors" in terms of software engineering - the term has a very specific meaning which is whereby programming instructions that are syntactically correct nevertheless produce erroneous return data.

What you're describing here is a situation where a system operating in the field has produced results that highlight potential issues going right back to the specification (or indeed a set of circumstances that the original specification did not or could not take into account) - which is what us nerds refer to as a "change request".

Now I've got that rather dull bit of nitpicking out of the way, let's dig in.
The above maybe confusing, perhaps because of the travail to explain.

Here is an explanation in other words, as a secondary source:
The "logic" behind a program is the "algorithm".
An "error in the logic" of a program is an "algorithm error".
A "software error" or "software bug", is one where the logic followed by the software is correct, but an incorrect outcome or result occurs, in spite of the correct following of the logic, or algorithm.

In high level programming languages a bug is usually caused by incorrect programming of data fields, which pass somehow through the compiler's checks, and which result in handling data which are different than what they're supposed to be. In machine language, which is often used in real-time programming, it may be a slightly wrong programming instruction which is equivalent to the previous mentioned error - for instance the use by mistake of a "load word" instead of "load byte", or "store byte" instead of a "store word", and others...

A "software syntax error" is a typo in a program instruction or program line, which is detected by the compiler - or some smart text editors - and need be fixed, before the compiler would complete successfully its processing.of the program source code. "Syntax errors' are never present in production/running software, as the process of generating the software excludes them.


According to the documenting of the algorithms by Airbus docs, the problems can be identified as being in the algorithms. Therefore, at this stage it seems that the solution of the problem is at algorithm level, not at software level.

Last edited by airtren; 14th Nov 2011 at 14:49.
airtren is offline  
Old 14th Nov 2011, 03:26
  #207 (permalink)  
 
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by OK465
Having once again learned something new here, in the future to avoid lag, I will plan on making all flight control inputs before I'm aware I need them.
Still, one question remains : How long before ?
Let's expect the answer to be somewhere here :




Lastly, I do not go with the yoke/wheel crowd. For some, the visual or tactile feedback might help. But mostly you see what's happening on the displays or outside the windshield and ask the other guy what he's doing if you don't understand what's happening.
The idea Gums is that such question has no reason as the visible yokes have already spoken. Next move on the yoke will tell if correction is applied and applied in the direction you would expect.

Instantaneous non verbal communication - Priceless - IMO - of course.
CONF iture is offline  
Old 14th Nov 2011, 03:37
  #208 (permalink)  
 
Join Date: Jul 2009
Location: The land of the Rising Sun
Posts: 187
Likes: 0
Received 0 Likes on 0 Posts
Diagnostic
Thank you for your courteous response.
I agree that Dr Bainbridge's paper is very valuable in this respect but feel that with good training and professionalism such an effect can be mitigated if not totally avoided. Pilots should not really freeze and lose control if an aircraft does what it is designed to. However, as realistic training as possible is the key hear and this may well be lacking. Hard training, easy execution as the saying goes. From my studies of previous airline company cultural issues I think that automation is the way to go but there are caveats as you observe.
Whilst you are correct about the hypothetical nature of my comments on yokes I feel that the balance of probabilities bears it out. Given the actions of the flight crew that night and that the PNF did take some ineffective action before calling the captain I cannot think that a different input method would have changed things. I also think that the PNF comments 2:10:26 to 2:10:36 where he tells the PF to go back down three times are highly significant and indicate an awareness derived from his instruments. The PNF also warns the PF (2:11) to 'touch the lateral controls as little as possible' once again indicating an awareness of what is happening. I would suggest that a yoke whilst not making the awareness worse it wouldn't have made it any better.
Old Carthusian is offline  
Old 14th Nov 2011, 03:51
  #209 (permalink)  
 
Join Date: Jul 2011
Location: Northern Hemisphere
Posts: 195
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by DozyWannabe
It didn't seem idiotic at the time, it wasn't just one person passing that information along and I had (and still have) no reason to believe that they would deliberately misinform me, in fact it's likely someone misinformed them.
So, from one source, there are now multiple sources of PMs.
Whatever the extend of the ring was, the idiotic message went around, and it seems that nobody alerted the Moderator to delegate the impersonation problem to him.

In fact the moderators deleted a whole swath of posts from that period and at no point was I contacted directly by the moderating team saying I had erred or otherwise - you make it sound like I was singled out for admonishment when it was not the case.
You have a problem with your parser - I said nothing to that effect.

But to help with your implying of unawareness of what was going on regarding your post, I will remind you that you were cc-ed on my communication to the moderator, so you were well aware of the link between your post, my reaction, my request to the moderator, and the removing of your post, so had plenty of info of why your post was removed.

Nevertheless you continued recently in two instances, with repeating the spreading of context of the older idiotic messages...

I have no access to the IP logs of this forum and therefore no way (or at least no *legal* way) of telling - other than building relationships with knowledgeable and trustworthy posters ....
This is so ridiculously amateurish ...

Do you need me to teach you how to act like a computer professional?

If you don't have access to the IP addresses, the Moderator does, and if he doesn't, the WEB master does, and so you should have asked the Moderator to look into it, if you had a suspicion, and wait for their answer, before posting publicly content of idiotic PMs... .

I am glad Organfreak made this sewer detective activities public, as it seems they went and go quite a bit.... Pfew, what a stink...

If the information was incorrect then, as I said, you have my apology. Other than that I don't know what more I can say or do at this point.
The enjoying of the mambo-ing around the "if" conditional sentence is your choice...

Last edited by airtren; 14th Nov 2011 at 14:52.
airtren is offline  
Old 14th Nov 2011, 04:59
  #210 (permalink)  
 
Join Date: Jul 2011
Location: Northern Hemisphere
Posts: 195
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by CONF iture

The idea Gums is that such question has no reason as the visible yokes have already spoken. Next move on the yoke will tell if correction is applied and applied in the direction you would expect.

Instantaneous non verbal communication - Priceless - IMO - of course.
CONF iture,
It's my opinion too.

Between visual and audio perception, the visual is a lot faster. It's not only the speed of light, versus speed of sound difference, but the speed of reaction to one versus the other stimuli to the brain.

Perhaps it would be helpful to share what race car drivers are taught:

widen the eye scan to over both sides of the track, and forward from front of car until as far as possible, and monitor any change of color, reflection, or shape that is abnormal. Upon detecting a change, focus on it, determine what it is, and react if necessary. The transition from monitoring to focus, to reaction is fractions of seconds, enough to have a correct reaction in time to avoid critical accident situations - as at the speed of a race car, in a second or two, the distance covered maybe too long....
airtren is offline  
Old 14th Nov 2011, 05:56
  #211 (permalink)  
 
Join Date: Jul 2009
Location: The land of the Rising Sun
Posts: 187
Likes: 0
Received 0 Likes on 0 Posts
There are two problems with that argument. Firstly, distance - at the distance in the cockpit the difference between audio and visual perception is so infinitesimal as to be totally disregardable. Understanding and interpretation are the key.
The second issue is that visual perception is worthless without a frame of reference and that is why a yoke is no more superior than a sidestick. A yoke moves - how far is a significant movement? Who decides the frame of reference?
Old Carthusian is offline  
Old 14th Nov 2011, 09:16
  #212 (permalink)  
 
Join Date: Jul 2009
Location: France - mostly
Age: 84
Posts: 1,682
Likes: 0
Received 0 Likes on 0 Posts
Cool

Originally Posted by DozyW
"We've latched stall warning because we can't trust the data, so at what point can we start trusting it again?"
CS 25.207(c) Stall warning:
Once initiated, stall warning must continue until the angle of attack is reduced to approximately that at which stall warning began.
So how about: IAS >60 kCAS and AOA(highest of 3) < SW threshold?

Last edited by HazelNuts39; 14th Nov 2011 at 09:30.
HazelNuts39 is offline  
Old 14th Nov 2011, 09:18
  #213 (permalink)  
 
Join Date: Jan 2006
Location: Sydney Australia
Posts: 2,302
Received 9 Likes on 4 Posts
Power+Attitude=Performance.

Or am I being too simplistic?
KRUSTY 34 is offline  
Old 14th Nov 2011, 09:32
  #214 (permalink)  
 
Join Date: May 2010
Location: EU
Age: 54
Posts: 22
Likes: 0
Received 0 Likes on 0 Posts
Causes and solutions vs justifications to do nothing...

In this case UAS was an incident where no intervention was actually required, just keeping Normal Law in force. With 3 A/S data loss, but knowing that A/S cannot suddenly change on large scale without a considerable acceleration being sensed , with at least 2 principle different source of data for speed (GPS, and inertial – acceleration derived ) – results that ‘simple’ changes are ‘at hand’ to software engineers for preventing pilot to be suddenly put in the control loop, when at least a warning time would be much more appropriate if not even allowing temporarily discrepancies/anomalies to be surpassed (and I am curious, in how many similar cases the time for ‘appropriate reactions’ of pilots and return to the initial trajectory were larger than duration of speed anomalies) .... .

But – no changes for speed sensors, no changes for F/Ctl software, no changes in pilot training – how many years?

And these not thinking about other means possible to develop: wing load can easily be deducted measuring strain in wing structure (using tensiometric sensors f.e.), wing deflection can easily be measured also, the conclusion is that flight being nowadays a mass service, authorities, insurers, carriers (in a word the whole industry ) treat it more and more as volume,( not quality/safety) driven.

Unfortunately , as in many other trades, the lie stay in what is not told to customer (or rarely escaped, and with smallest font written) and even to industry professionals too. It seems that remain to judges to make that policy too expensive, (but, little hope too...)
alexd10 is offline  
Old 14th Nov 2011, 11:16
  #215 (permalink)  
 
Join Date: Oct 2009
Location: UK
Posts: 1,270
Likes: 0
Received 0 Likes on 0 Posts
@ Old Carthusian,
A yoke moves - how far is a significant movement? Who decides the frame of reference?
The PNF's frame of reference is relative to his seat position just before the zoom climb. Significant movement is some inches before the yoke is in your chest - in your chest is excessive.
rudderrudderrat is offline  
Old 14th Nov 2011, 12:49
  #216 (permalink)  
 
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by HN39
So how about: IAS >60 kCAS and AOA(highest of 3) < SW threshold?
I would not disagree.
Still, IMO, the single condition AOA(highest of 3) < SW threshold would be enough to satisfy the CS 25.207(c) you did mention.

Originally Posted by Old Carthusian
A yoke moves - how far is a significant movement? Who decides the frame of reference?
It is not much who but rather what decides the frame of reference ?
Experience, experience does that. A student pilot is already able to appreciate that half travel displacement of the yoke is usual for takeoff or landing phases but unsuited for cruise speeds.
CONF iture is offline  
Old 14th Nov 2011, 12:52
  #217 (permalink)  
 
Join Date: Jan 2008
Location: uk
Posts: 857
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by AlphaZuluRomeo
For the record, and despite I doubt it would have changed the outcome in the light of the crew actions, I see two of them:
1/ the non-inhibition of the nose-up autotrim when stall warning is active
2/ the inhibition of the stall warning under 60kt IAS (even if I understand the logic behind the inhibition, I still think it may be worth reworking that bit of logic)

And perhaps a 3rd and 4th, but as I don't know the logic behind I'm not qualified to fully comment:
3/ the V/S switching source from air data to inertial (and back); it occured in AF447 and its consequence was a non-readable/unreliable/unrealistic displayed (air data sourced) V/S, while at the same time a reliable/realistic V/S value (aka inertial sourced V/S) was available (for the system).
4/ the non-inhibition of the F/Ds (by the system) when an UAS situation is detected: why? A/P & A/THR may (and have) been dropped, why not the F/Ds as they may give unreliable directions in such a situation?
I agree with those, with some caveats.

1/ Not sure about preventing upward trim only - you then turn THS into a control that can only ever ratchet nose-down which doesn't sound good. Maybe a fixed travel limit, but you'd need to ensure that the available range will give you all the control you need in the event you've got to a continued false stall warning. The whole autotrim area needs looking at in and out of stall IMO - too many incidents of autos trimming up into a stall and then handing the pilots the problem. It isn't going to be a simple problem with an easy answer though.

2/ I wouldn't be suprised if this was at very low level "close" to the senosrs and in hardware rather than software. Whether you term hardware issues "bugs" or not, it's a design issue (right down to what the AOA and pitot probes actually dleiver) that needs looking at.

4/ I think they do inhibit, may depend how you get into UAS though. But the switching in and out has got to be distracting and potentially confusing. Hence something with some real intelligence should switch it out and bring it back when things are properly understood and stable again. Now, what's the first UAS memory item again...


I'll also throw in another potential design issue, with the caveat that I'm also "not qualified to fully comment":

5/ the system notifies / warns of UAS, and changes control law etc., all well and good but where is that notification to the crew when the speed sensing is ok again ? I'm not sure there is anything (or nothing explicit) ? These pitot failures have been held up as transient events, lasting tens of seconds. They are being (mostly) correctly detected (but not prevented) by the built in checks and redundancy. But if the system never reports a return-to-normal, how is the crew to know ?

I believe this crew were still attempting to troubleshoot the UAS event well after it had passed, and when they should have been troubleshooting their real (correctly indicated) airspeed being fatally low.
infrequentflyer789 is offline  
Old 14th Nov 2011, 12:54
  #218 (permalink)  
 
Join Date: Jan 2008
Location: uk
Posts: 857
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by KRUSTY 34
Power+Attitude=Performance.

Or am I being too simplistic?
And maybe they were trying that in the later stages. Doesn't work too well when stalled...
infrequentflyer789 is offline  
Old 14th Nov 2011, 13:58
  #219 (permalink)  
 
Join Date: Aug 2011
Location: Grassy Valley
Posts: 2,074
Likes: 0
Received 0 Likes on 0 Posts
320 has three degree -THS limit in Alternate. As above, it is stated that the 330 DOES NOT. That is an assumption based on the DFDR related to AF447. (THS migrating to Full NU and staying).

GOSPEL? Why indeed would the logic be changed? Wouldn't it be consistent in the family? I have read it here, but not in the words of programming experts.

Who has knowledge why the debut airframe would be different in AB NORMAL LAW/ALTERNATE2 than the A330?

As has been expressed here by others, AUTOTRIM in other than expected/normal conditions is considered unwelcome. What is the genesis of AL2 AUTOTRIM past 3 degrees (-)? Especially when mindful of the family DNA.

FALSE SW defeat notwithstanding?
Lyman is offline  
Old 14th Nov 2011, 13:59
  #220 (permalink)  
 
Join Date: Jul 2009
Location: France - mostly
Age: 84
Posts: 1,682
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by CONFiture
the single condition AOA(highest of 3) < SW threshold would be enough to satisfy the CS 25.207(c)
Not if the AoA gets the value zero for <60 kCAS.
HazelNuts39 is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service

Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.