A33Zab

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.

auraflyer

Thanks A33Zab - point taken, and you have confirmed my initial reluctance to post my thoughts.

CONF iture

That's the answer to an UAS after opening the QRH.

But this one is very different as it was the answer to a stall warning.

DozyWannabe

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.

rudderrudderrat

Hi 33Zab

I agree but would add:
& it will maintain pitch attitude all the way to the stall threshold.

but it is now longitudinally speed stable.

A33Zab

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.

Chris Scott

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.

HarryMann

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..

RR_NDB

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

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)

BOAC

RR - re your 1) - that is why I suggested the FDR be 'biased' to PF rather than LHS as appears at present.

Lonewolf_50

Catching up has been most informative. A couple of issues that caught my eye.
1. 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.
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. 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.

gums

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.

DozyWannabe

Not necessarily, remember we don't have a complete picture of the PNF's actions and reactions as yet!

PJ2

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.

syseng68k

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...

Khashoggi

^^ your not wrong. Your spot on.

PA 18 151

Like a stall warning perhaps?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.

syseng68k

Svarin, #784

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...

RR_NDB

PJ2My 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

syseng68k R&D is necessary! Not a simple Development.

With the trend towards System complexity this may get worse. Again, R&D is necessary! Not a simple Development.