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

AF 447 Thread no. 4

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

AF 447 Thread no. 4

Old 5th Jul 2011, 10:02
  #801 (permalink)  
 
Join Date: Jun 2009
Location: somewhere
Posts: 451
@ auraflyer:

(b) when things go wrong, errors are expressed in terms of each "protection" that is lost -- one indication for each protection lost (or, where there are multiple levels of degradation, what degree has been lost and what is left).
O no, even as engineer I don't think a crew do like (and has the time) to read a novel on his ECAM.

The rules are simple:

NORMAL = I can do with the stick what I want.
ALTERNATE = I have to be gentle with the stick because I lost the protections.
DIRECT = I have to be very carefull with the stick because movement equals control movement.

There's more to Law degradation than only the pitch channel, other functions are inhibited or arranged in another way and/or during flight phase change.
A33Zab is offline  
Old 5th Jul 2011, 10:08
  #802 (permalink)  
 
Join Date: Jan 2008
Location: Australia
Posts: 50
Thanks A33Zab - point taken, and you have confirmed my initial reluctance to post my thoughts.
auraflyer is offline  
Old 5th Jul 2011, 10:42
  #803 (permalink)  
 
Join Date: Jan 2005
Location: W of 30W
Posts: 1,939
Originally Posted by A33Zab
Au dessus de 190T; FL 250 a FL 370
Vitesse 260Kts: Assiete (Pitch) 3.5 / POUSSEE (Thrust?) N1 90%
That's the answer to an UAS after opening the QRH.

Another 20% is a considerable amount of thrust (and pitch-up) they put in when moving T/L to TOGA. (=100% thrust).
But this one is very different as it was the answer to a stall warning.
CONF iture is offline  
Old 5th Jul 2011, 10:53
  #804 (permalink)  
 
Join Date: Jul 2002
Location: UK
Posts: 3,182
Originally Posted by PA 18 151 View Post
2) They misunderstood, or were confused by, what they were being shown

My money is on 2)
Not that I want to get into a semantics parsing issue, but misunderstanding is *not* the same as confusion, except maybe as a literary device - for example I've always considered "mode confusion" to be a misnomer, as accidents involving mode "confusion" rarely showed the pilots unsure of the setting they'd selected - they were convinced that they were in the right mode, all the way down to the ground in many cases. I think it means what it says - that they weren't getting any valid readings on an instrument (or possibly instruments), my money being on the ASI.
DozyWannabe is offline  
Old 5th Jul 2011, 11:08
  #805 (permalink)  
 
Join Date: Oct 2009
Location: UK
Posts: 1,271
Hi 33Zab

I agree but would add:
NORMAL = I can do with the stick what I want.
ALTERNATE = I have to be gentle with the stick because I lost the protections.
& it will maintain pitch attitude all the way to the stall threshold.

DIRECT = I have to be very carefull with the stick because movement equals control movement
but it is now longitudinally speed stable.
rudderrudderrat is offline  
Old 5th Jul 2011, 12:01
  #806 (permalink)  
 
Join Date: Jun 2009
Location: somewhere
Posts: 451
@CONF iture:

I know and maybe I was not clear in the question, with excuses.

I tried to figure out what would be the initial movement from the Thrust locked condition. as this was the first ECAM drill "THR LEVERS....MOVE" @ 2:10:05.
Don't think they waited untill 02:10:51 to perform the drill, so the T/L was initially moved to a position between CLB and TOGA.

if the UAS value is known, which is safe pitch/thrust relation, it would be more or less the position of the A/T N1 value with T/L in the CLB detent before the event (transient IAS speed loss) took place.
So the initial THR LEVERS.....MOVE action was movement of T/L fwd to intercept ~ 90%N1.

Thanks for info.
A33Zab is offline  
Old 5th Jul 2011, 12:17
  #807 (permalink)  
 
Join Date: Jan 2008
Location: Blighty (Nth. Downs)
Age: 73
Posts: 2,091
ASI 2

Quote from PA_18_151:
At 2 h 12 min 02, the PF said "I don’t have any more indications", and the PNF said "we have no valid indications".
That, to me at least, indicates confusion. Either
1) There were no valid indications
or
2) They misunderstood, or were confused by, what they were being shown
My money is on 2)

Agree. It's a puzzling exchange, and the reason I'm still not entirely convinced that ASI2 was giving similar, intermittent, under-readings as ASI1 and the ISIS ASI. On the face of it, Pitot1 and Pitot2 might be expected to suffer similar icing characteristics, as they are symmetrically situated. But their heating performance might not have been identical on the night. This brings me back to a possibility others were discussing yesterday, which has been nagging me since May27.

It is possible to infer from the PF's remark that he had recently been relying on an indication that had just been removed. The words seem to have been spoken some time after they had passed FL350 in the descent. If the Pitot2 had been blocked both at intake and drain-hole, this would not explain the INITIAL pitch-up that we assume the PF made from FL350. But once the climb had been started, the ASI2 readings would have gradually increased to the FL380 apogee, then gradually decreased in the (stalled) descent. Simplistically, if Pitot2 remained completely frozen, the ASI2 reading would have dropped to the original cruise value when the static source (thought) the aircraft was passing FL350 in the descent. After that, the ASI2 reading would progressively drop to zero.

Although I think the above scenario is unlikely, because the trap is understood by most pilots, it would be frustrating if it cannot be disproved by QAR data or otherwise.
Chris Scott is offline  
Old 5th Jul 2011, 12:58
  #808 (permalink)  
 
Join Date: Jan 2008
Location: Herts, UK
Posts: 743
The 'bus looks to be a very well designed jet, or you couldn't have a "deep" stall, or a deep stall, for over 3 minutes without going into a spin or worse.
That crossed my mind too, a long [stable]descent without lateral divergence or serious oscillatons

Even Airbus might not have credited that degree of spin-resistance... just needed a giant hand to tilt it down again and a PIC to let that stick alone....

It doesn't condemn sidesticks out of hand, but it certainly does their reputation no favours, especially since their detractors have been saying this sort of thing for years; about immediate, indisputable visual & mechanical position feedback. Feel would also be a good deal more intuitive (to the hands rather than the odd finger, whether recently blood blistered at home doing DIY or not).

Fact is, however small or large part of this sequence the physical pitch control device is... it did happen (stick held back) and is relevant.

Now the Captain of DH 121 Trident BEA 548, may well have fought the stick (shaker) all the way down, indeed it was soon switched off, but that was not a long descent, thankfully just a few tens of seconds... so we'll hopefully not make comparison here..

Last edited by HarryMann; 5th Jul 2011 at 13:38.
HarryMann is offline  
Old 5th Jul 2011, 13:46
  #809 (permalink)  
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 873
Intriguing climb, current FDR capabilities and AF447 analysis

PJ2 and CJ in recent posts, commented on FDR capabilities:

I'm genuinely interested in any push to improve flight data recording
I 'did' FDRs late in my engineering career, so at least I'm familiar with the concepts
I need to present 3 (conceptual) questions (important to the analysis and understanding of the intriguing climb):

1) All information (except WX radar) being presented to PF and PNF are normally recorded in the SSFDR used in AF447? RHS not recorded could affect the investigation team analysis capability? Could affect the analysis in order to to understand PF (if confirmed at RHS) behavior?

2) Internal System information like redundant inputs to the System (e.g. individual ADM outputs) are recorded?

3) Internal information (of the System) is recorded to allow a clear analysis of how System operated when something (anything) affects the "redundancy degree" of the System? (causing it to operate less redundantly)
RR_NDB is offline  
Old 5th Jul 2011, 14:56
  #810 (permalink)  
Per Ardua ad Astraeus
 
Join Date: Mar 2000
Location: UK
Posts: 18,583
RR - re your 1) - that is why I suggested the FDR be 'biased' to PF rather than LHS as appears at present.
BOAC is offline  
Old 5th Jul 2011, 14:58
  #811 (permalink)  
 
Join Date: Aug 2009
Location: Texas
Age: 61
Posts: 5,521
Catching up has been most informative. A couple of issues that caught my eye.
1.
The question jcjeant should really be asking is why was the PF trying to use aileron to counter wing drop.
If you refer to a post stall roll problem, PF probably didn't know he was stalled. Others have answered in more depth with notations on the BEA report timelines. Had he known he was stalled, I suspect he'd have dropped the nose.
At the point in question, AF447 was already in a super-stall, although we have to assume that the PF had not diagnosed it.
Not early in the event. That "super-stall" was after the climb's apogee. The roll inputs appear to have been a running battle from early in the alt law event.
2.
If we knew the reason for the nose up pitch inputs, we would be well on the way to understanding the accident. IMHO, inadvertent pitch input while controlling the roll axis seems to be the most likely cause. Alt 2 is a funny law. You have to stay off the pitch axis, but fly the roll axis. That does not seem trivial to me.
How often does one practice this flight control problem? If you don't train for the difficult flying tasks, you'll tend to perform them poorly.

When I was a flight student, I didn't much care for simulators, and made such complaint one day to my instructor. He gave me a "come to Jesus" lecture (brief, but powerful) about how important rehersal is for performance. He used the football game prep as an analogy:

"You practice the way you intend to play. Any play you don't practice will tend not to work on the field at game time. Any chance you get to rehearse, or to practice, you take, and you make the most of it." (Add a few more words meant to get my attitude properly adjusted. )

Years later, I heard a similar cliche from a different source: "train the way you intend to fight, and you'll fight better." It was in reference to the Fort Irwin National Training Center. (Armored warfare training with serious intensity/complexity).

3. This post is a nice one by PJ about how one trains one's crews.
http://www.pprune.org/tech-log/45465...ml#post6551107

It's an AF matter, but a matter that influences how well their pax are taken care of.
Lonewolf_50 is offline  
Old 5th Jul 2011, 15:09
  #812 (permalink)  
 
Join Date: Jun 2009
Location: florida
Age: 77
Posts: 1,200
Basic control law, et al

TNX for nice words, Aura. And A33Z seems to homing in on the concept I advocate - to some extent.

There is absolutely no reason to diminish the capabilities of a FBW system in the "basic" law.

- Nz and alpha for pitch commands, roll rate command and HAL stops when control pressure released, with some body rates and control surface aero characteristics and servo-actuator limits and.... all thrown into the mix. This is the same as all the direct hydraulic systems we have had since the F-86 and some British lites way back in the 50's. In those days, the hydraulic pressures were physically modified between the control stick/wheel/yoke and the final control surface movement ( rate and deflection).

- In the most basic "law", I have a jet that flies like all jets, but more precise bank control and a known pitch command if I release the stick/yoke in any axis. For a heavy, I like the 'bus implementation, as it's biased about a one gee command. My Viper could be trimmed for a gee at neutral stick ( minus 2 or so and plus 3.5 gee), but this doesn't seem practical for a heavy.

- All the bank angle and pitch angle stuff seems more like an autopilot function, and is all well and good until things break. What I want and need (as do all the SLF's paying to have a safe, comfortable ride), is something to hang my hat on.

With all the discussion about the air data being unreliable or completely FUBAR, I can't understand the lack of a simple "standby gains" feature that HAL uses for "q" and total pressure. Ours was about 140 knots gear down and 300 knots gear up. So yeah, if flying at the speed of stink the jet was twitchy ( technical term we lite jocks use), and if slow the jet was sluggish. But we still had alpha limits, rate limits, gee limits, and the beat goes on. NOBODY COMPLAINED. We never lost a jet if the air data went south except for the pelican strike that took away AoA, pitot-static and had damage to the actual FLCS computers just in front of our feet. Big deal.

In other words, a basic loss of the air data is no big deal, and we can throw out all the 'protections" and simply have a basic, well-designed jet to fly until we get all the right inputs back in the green. I am confident that even a newbie flight officer could fly the jet at almost any flight condition if this were the case. I would not pay my fare if I didn't believe this.

My concern of the accelerometer and rate inputs to HAL is valid, IMHO. They should be embedded in the basic FLCS, and should be the "core" of the system.
gums is offline  
Old 5th Jul 2011, 16:10
  #813 (permalink)  
 
Join Date: Jul 2002
Location: UK
Posts: 3,182
Originally Posted by HarryMann View Post
It doesn't condemn sidesticks out of hand, but it certainly does their reputation no favours, especially since their detractors have been saying this sort of thing for years; about immediate, indisputable visual & mechanical position feedback.
Not necessarily, remember we don't have a complete picture of the PNF's actions and reactions as yet!
DozyWannabe is offline  
Old 5th Jul 2011, 16:51
  #814 (permalink)  
PJ2
 
Join Date: Mar 2003
Location: BC
Age: 72
Posts: 2,439
RR_NDB;

My responses in blue font:

"I need to present 3 (conceptual) questions (important to the analysis and understanding of the intriguing climb):

Let me preface my comments by stating again that I support and advocate for any and all ways to improve flight data recording.

To take FDR from its present state to the state you envision requires an understanding of all aspects of flight data recording and analysis. Any such understanding also requires a keen understanding of how flight data analysis actually works in practise. Such an understanding addresses the view that "if only we had ALL the information we could determine what happened." A detailed recording of "all" parameters is not necessarily a solution to understanding what happened. "All parameters" may not be needed, not because it can't or shouldn't be done but because such fine granularity may not be necessary. I can tell you that such granularity is unbelievably expensive to do, especially any retro-fitting, which brings me to the point I made in my first response - what is available in terms of parameters is driven purely by money, not flight safety or our need to know absolutely everything that goes on in each of the EEPROMs, computers and systems. The industry is just not going to pay for such a system even though, from an understanding POV, a case can be made.

"1) All information (except WX radar) being presented to PF and PNF are normally recorded in the SSFDR used in AF447? RHS not recorded could affect the investigation team analysis capability? Could affect the analysis in order to to understand PF (if confirmed at RHS) behavior?

No, not necessarily. I took some trouble to discuss FDRs in Post #715, were you able to read it? There are no formal (legal) requirements for recording all such information and I describe why in the post. The fact that the #2 AS was not recorded is nothing more than it likely wasn't considered necessary, the airspeed already being "covered" by recording the #1 and the Standby, (and that is already well beyond minimum requirements).

It must be kept in mind that what is recorded is a matter of LFL, (logical frame layout) construction. Beyond the 88 legally-mandated parameters, this is not a process which is specified beyond the manufacturer. Boeing may have several hundred data frames for the B737 type for example, and they will be very different because the aircraft are very different. For older aircraft especially, DFDR and QAR data frames are specific to the individual aircraft simply because these aircraft get modified by successive owners who may desire certain parameters over and above the legal minimums. Many aircraft flying today only record the legal minimum and (from experience) it is not the case that all parameters are even working or recording correctly.

The SSFDR on AF 447 recorded, we are told, about 1300 parameters. Many of these parameters will have been the engine and engine system parameters, primarily used by maintenance for troubleshooting. Comparatively speaking, the requirement to "troubleshoot" EFCS components is rare - the boxes are pulled from the 800VU rack, sent to the manufacturer for troubleshooting/repair and a new (multi-million dollar) box is placed in the rack. The SSFDR will not have recorded very many EFCS parameters because it is not the airplane manufacturer's job to supply such parameters - it is done as a matter of discussion between the various parties...manufacturers, airlines, sometimes even flight safety people or pilots.

One great frustration in doing flight data analysis work is, as you point out, not knowing what the crew saw in terms of text messages on the FMA, the Lower ECAM, the status page and so on. To do so is very expensive because the data frame must be programmed to receive these parameters in binary format and change them into engineering units or text messages, but it is assumed that the computers (FWC in the A330's case) are correctly sending these messages to be displayed for the crew and the process therefore isn't necessary.

"2) Internal System information like redundant inputs to the System (e.g. individual ADM outputs) are recorded?

For the reasons given above, it can't be said whether they are or not. It can be done, but likely is not.

"3) Internal information (of the System) is recorded to allow a clear analysis of how System operated when something (anything) affects the "redundancy degree" of the System? (causing it to operate less redundantly)"

Again, not necessarily, for the reasons given.

=====Discussion:

The other important approach to flight data analysis work is not making the mistake of believing that "if only one had enough data, we could say exactly what happened". There are two reasons why this mistake is made:

1) Complex accidents such as AF 447 require that the work is very often interpretive and not just a summary of all the parameters in order of "causality". This is not a function of the available information, it is a function of ensuring that, a) human factors, and b) the nature of the data-recording process, are both taken into account when trying to understand (interpret) what the data is saying. How one "builds the story from mere data" is an entirely interpretive act requiring knowledge, skill and experience to do accurately.

2) The second reason is the nature of the recording process itself. In the same way we could never just look at the time-stamps on the ACARS messages and say that's the order in which things occurred, the problem of timings, sequence and therefore causality, is Vast if one is recording every EEPROM state, decision and output. The CAP 731 AAIB document to which I referred discusses data frames, recording frequency and binary-to-engineering conversions. It may be readily understood that recording frequencies can vary from say, every four seconds, (for fuel quantities) to four times a second (for pitch or roll, and pitch/roll rates), to sixteen times every second (for gee). But if you wish deep granularity we could argue that many parameters should be recorded at 26 frames per second, or data at video rates. The processes are entirely open to design capabilities and the imagination and at the same time are limited by the practicalities of cost and need.

One may find answers in the millions of parameters which would be required to capture such a level of data but the questions of practicality, of capability, of need and of expense all have contributions to make in such a discussion regarding whether to create such a system or not.

In most investigative work, (I am not an accident investigator), the number of parameters required to reach good conclusions is surprisingly small where the described knowledge, skill and experience are available. A clear example of this principle at work is the investigation into the QF72 PRIM incident. Indeed, the aircraft is not the only source or place to derive data; the manufacturer will have source code, testing facilities and their own experts who know how the computer(s) should behave and, if they didn't (as in the QF72 case), why they didn't.

While we await the next report from the BEA, I genuinely hope that this is helpful RR_NDB.
PJ2 is offline  
Old 5th Jul 2011, 16:55
  #815 (permalink)  
 
Join Date: Jun 2009
Location: Oxford, England
Posts: 297
gums, #791

Have been thinking about the application of technology. At opposite ends of the spectrum, we have two motives:

1) To simplify complex processes.

2) As an exercise in intellectual self abuse, to demonstrate how clever it all is.

After being shocked at times by the revelations in this thread during the past couple of years, i'm not really sure where the application of technology is taking us w/regard to aviation. If the primary focus for this is towards improved safety, then they have failed imho. While the technology has resulted in various control laws to improve safety and efficiency, it's application looks like a camel and has done nothing to improve the chances of safe recovery in an emergency, just at the time when it's most needed. Not smart enough by half, in that an appropriate function would, for example, recognise things like pf commanding a zoom climb or other sequence of events outside the expected operating conditions at a given stage of flight and at least provoke the suggestion that it is perhaps not a good idea. "I'm sorry, but I can't do that Dave", springs to mind. Perhaps amusing, but the sort of thing that could contibute to safe operation. I'm not arguing for more or less automation, but more intelligence in terms of trend analysis, resolution of ambiguous situations and timely warnings where operation is tending towards potentially dangerous situations.

Found the 4 part a330 fcom on the web a couple of weeks ago. I couldn't help thinking how much it reminded me of consumer electronics user guide, rather than a proper technical manual. A full TM would describe (eg) how all the various information sources logically combine, their values and conditions, to initiate the transitions between the various control laws, in tabular or flowchart form. While you do get some of this in the user guide, it's spread bits and pieces style all over the place, making it more difficult to visualise the big picture. Quite a disappointment really and if I were a pilot flying one of these boxes, it's something I would need to understand, for all kinds of reasons.

To paraphrase your sentiment, if the crew ever find themselves in a situation where the state of the a/c is not resolvable within a few seconds, in a completely unambiguous way, then the design is at fault and technology has not been applied correctly. There's really no excuse for this at all, however it's spun.

Away doing some real work for a couple of weeks and looking afresh, find myself in quite critical mood. Correct me if i'm wrong here...
syseng68k is offline  
Old 5th Jul 2011, 17:09
  #816 (permalink)  
 
Join Date: Jun 2010
Location: SBA
Age: 52
Posts: 34
^^ your not wrong. Your spot on.
Khashoggi is offline  
Old 5th Jul 2011, 17:19
  #817 (permalink)  
 
Join Date: Apr 2011
Location: NottNum
Posts: 25
Originally Posted by syseng68k View Post
Not smart enough by half, in that an appropriate function would, for example, recognise things like pf commanding a zoom climb or other sequence of events outside the expected operating conditions at a given stage of flight and at least provoke the suggestion that it is perhaps not a good idea.
Like a stall warning perhaps?
I'm not arguing for more or less automation, but more intelligence in terms of trend analysis, resolution of ambiguous situations and timely warnings where operation is tending towards potentially dangerous situations.
From the Evidence (fact)

  • At 2 h 10 min 51, the stall warning was triggered again........
The aircraft appeared to do exactly the sort of thing you are saying it should.

There isn't a lot of evidence, but what there is is quite powerful stuff.
PA 18 151 is offline  
Old 5th Jul 2011, 17:22
  #818 (permalink)  
 
Join Date: Jun 2009
Location: Oxford, England
Posts: 297
Svarin, #784

By the way, if someone could please enlighten yours truly regarding the
certification process applied to flight controls computers software
versions released after the initial certification process, I would be
extremely grateful.
If you want to get an idea of what's involved in the development process,
you could google "DO178 standard" for a start. You probably won't find
the whole document unless you pay for it (expensive), but you will get a good
overview. It's not just about software development standards, but also
about the ways that the various parts of development chain link together, in
an effort to eliminate pathways that could result in errors. In the case of
software updates, full regression testing would be required and more to ensure
that changes in one area haven't broken anything else.

I think that if there were bugs (unlikely), they would be found at the level
of subsystem interaction, where timing issues and concurrency make it much
more difficult to model at the design stage. That in terms of the myriad
possible failure scenarios and their timing at the limits of
system capabilities. This would be a systems engineering, managing complexity
issue and not one of software as such. Seems very unlikely that there would
be any significant bugs in the individual subsystems, as their behaviour is
tightly defined and thus easier to model in design and subsequently testing...
syseng68k is offline  
Old 5th Jul 2011, 18:12
  #819 (permalink)  
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 873
I can now prepare to present some ideas

PJ2
I genuinely hope that this is helpful
...I support and advocate for any and all ways to improve flight data recording

My concern is about important internal (volatile) info that would be lost (if you don´t record it). Without this approach you may face situations (during the investigation) that do not allow us to reach a (reliable) conclusion. One may argument you may just look to inputs and outputs of the “engineering black box” . But i suspect that in certain situations (when you are inside, participating of the feedback loop) and the System is under failure mechanisms you need internal data to understand pilot actions. I strongly suspect the way the approach the recording is (still) made is more effective to put responsibilities on crew errors.

Thanks for the extra motivation. In my answer i will try to contribute with some ideas concentrated (like CJ mentioned) on conceptual aspects.
RR_NDB is offline  
Old 5th Jul 2011, 18:13
  #820 (permalink)  
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 873
"where the application of technology is taking us" (Av)

syseng68k
I'm not arguing for more or less automation, but more intelligence in terms of trend analysis, resolution of ambiguous situations and timely warnings where operation is tending towards potentially dangerous situations.
R&D is necessary! Not a simple Development.

...has done nothing to improve the chances of safe recovery in an emergency, just at the time when it's most needed.
With the trend towards System complexity this may get worse. Again, R&D is necessary! Not a simple Development.
RR_NDB is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service - Do Not Sell My Personal Information

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