TAM A320 crash at Congonhas, Brazil
Join Date: Dec 1999
Posts: 182
Likes: 0
Received 0 Likes
on
0 Posts
I'd really like to know what happened in this accident. There are several thousand posts in this thread and I really don't want to read them all. Does anyone know if there is a good post which sums up what happened buried in this thread somewhere?
Per Ardua ad Astraeus
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
Ok - here's my go:
Flight landed on a wet ungrooved runway at CGH with No2 reverser locked out under MEL. For an as yet undetermined reason a significant forward thrust well above idle was maintained on No2 engine, with reverse selected on No1.
Accordingly the spoilers did not deploy, and the a/c left the left-hand end of the runway (35L) and impacted with a building killing all on board.
We await the accident findings.
We do not think that we have the full CVR available (here) nor possibly the full FDR. Rumours and speculation abound as usual.
Flight landed on a wet ungrooved runway at CGH with No2 reverser locked out under MEL. For an as yet undetermined reason a significant forward thrust well above idle was maintained on No2 engine, with reverse selected on No1.
Accordingly the spoilers did not deploy, and the a/c left the left-hand end of the runway (35L) and impacted with a building killing all on board.
We await the accident findings.
We do not think that we have the full CVR available (here) nor possibly the full FDR. Rumours and speculation abound as usual.
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes
on
0 Posts
BOAC gives a good summary.
For a state-of-public-knowledge causal analysis, see the commentary and Why-Because Graph at
http://www.rvs.uni-bielefeld.de/publ...s/TAM3054.html
The analysis is incomplete, because data on training/airline issues and regulatory issues are not included, since these are being negotiated and not yet stable.
PBL
For a state-of-public-knowledge causal analysis, see the commentary and Why-Because Graph at
http://www.rvs.uni-bielefeld.de/publ...s/TAM3054.html
The analysis is incomplete, because data on training/airline issues and regulatory issues are not included, since these are being negotiated and not yet stable.
PBL
Join Date: Jan 2001
Location: Dallas, TX USA
Posts: 739
Likes: 0
Received 0 Likes
on
0 Posts
Who's got the airplane?
In my glider club when flying 2 seat gliders, the procedure for handing control of the airplane from one pilot to the other is; PF – “You have the airplane”, PNF – “I have the airplane”, or vis-versa, depending on who initiates the control transfer. In automated systems, control transfer is not always this clear (but should be). In previous posts I’ve quoted Jef Raskin, but now I’ll start quoting Charles Billings (specialist in aeromedical research who has worked for NASA). Here’s an interesting summary article regarding his theories, which he wrote a few years ago discussing human factors in automated systems and aviation.
http://www.ifp.uiuc.edu/nsfhcs/talks/billings.html
He defines a series of principles regarding the human factors in the design of automated systems. Each item listed below is explained a little more clearly in the summary article.
First Principles of Human-Centered Systems
My aviation career was in flight simulators long ago, but my more recent experience has been in business, and I've dealt with the automation of business processes for more than 2 decades now. In that time, I've seen a lot of mistakes with automation, and I've come up with my own list of rules for the proper application of automation to processes. I think some are applicable to aviation.
Curt Graeber, Chief Engineer Human Factors Engineering, of Boeing, made the following comments in a Boeing Aeromagazine article.
One of the most common mistakes I see in automation is attempts to over automate processes. The result is a process that fails unexpectedly for mysterious reasons and without timely notification of the failure to the process monitors and operators. I think one of the reasons for this is the idea of artificial intelligence where a computer and software can accommodate all variables and all conditions. In reality this is fiction and is not possible. The computer will always be limited by the flow chart and the logic built into the program. It can never do more that the sum of its program logic, and that logic can never accommodate all possible variables and conditions. Because the human mind is more creative and an infinitely better problem solver, it will always be the smartest computer in a process. The computer however can assist the human in its main weakness, which is making mistakes when performing routine repetitive tasks. The strength of each can accommodate the other's weakness, as they are very complimentary.
In the A320, I believe the design philosophy was overly ambitious from the beginning. The A320 was the first of it's kind in FBW airliner design, and l believe later designs have learned from the A320 experience.
In Bernd's post #1837 he said,
I think it's not really this simple. How wonderful to think an automated system could make the speed control of an airliner this simple, but in reality it cannot. This represents an overly ambitious design effort that cannot accommodate all the variables and conditions one can encounter.
From my Six Sigma training and time spent applying it, I have learned that exceptionally low error rates usually only happen in manufacturing environments where the variables can be limited and controlled. In service oriented processes, the variables are usually much larger in number and many are usually beyond control. The human often has to intervene is these cases. It’s much easier to control the variables when manufacturing an airliner, than it is to control the variables when an airliner is used in service.
The landing of an airliner is not always predictable and the human is subject to making an error when performing a repetitive task during landing. Thus I find it hard to believe that the pilots of the TAM A320 were allowed to get into the situation that killed them. Once they deployed thrust reverse on ENG1 while leaving ENG2 thrust lever in the CLB detent during touchdown, the accident had already happened. Correct me if I’m wrong, but doesn’t the 737 for example prevent such an occurrence (with a lockout), by not allowing the pilot to put an engine in reverse if the other throttle lever is not in idle? This preserves the go-around option which was lost with the TAM A320.
Who has the airplane in regards to speed control? Once the pilot selected reverse thrust for ENG1 in those conditions, who had control over the aircraft’s speed on the ground? Because the airplane allowed the asymmetric reverser deployment (automation or even mechanically not watching over the pilot), the ground spoilers and auto brakes did not respond correctly to these conditions. Yes, these systems responded to their control logic, but that was all they could do, as they could not go beyond their control logic to assist in this particular set of circumstances. Of course there was no override of the ground spoilers available to the pilots (overly ambitious automation design that assumed it would never be needed), which I’m sure they would have used (if available) due to the fact that they cycled the arming of the spoilers to try and stop. They had manual brakes, but no manual spoilers, thus who had control over the speed of the airplane on the ground was ambiguous.
I think the H2F3 software modification is helpful, but less than a satisfactory solution. I think it better to prevent the pilots from entering into this single TR thrust lever coffin corner, than to warn them about it once they’re in it already.
I could go on, but will stop here as I have to go.
http://www.ifp.uiuc.edu/nsfhcs/talks/billings.html
He defines a series of principles regarding the human factors in the design of automated systems. Each item listed below is explained a little more clearly in the summary article.
First Principles of Human-Centered Systems
- Premise: Humans are responsible for outcomes in human-machine systems.
- Axiom: Humans must be in command of human-machine systems.
- Corollary: Humans must be actively involved in the processes undertaken by these systems.
- Corollary: Humans must be adequately informed of human-machine system processes.
- Corollary: Humans must be able to monitor the machine components of the system.
- Corollary: The activities of the machines must therefore be predictable.
- Corollary: The machines must also be able to monitor the performance of the humans.
- Corollary: Each intelligent agent in a human-machine system must have knowledge of the intent of the other agents.
My aviation career was in flight simulators long ago, but my more recent experience has been in business, and I've dealt with the automation of business processes for more than 2 decades now. In that time, I've seen a lot of mistakes with automation, and I've come up with my own list of rules for the proper application of automation to processes. I think some are applicable to aviation.
- The automated process design must always remain customer focused (meaning error free outcome focused).
- The smartest computer in the process in the only one that can think outside the limitations of the flow chart (the human computer).
- Do not try to design to accommodate all problems, all variables and all situations, because you can't. At best you can only accommodate the most common problems, the human operator will have to take care of the rest.
- Keep the human operator informed at all times of the state of the process.
- Build in secondary flow paths wherever possible, so the process can continue in a degraded mode, while the primary flow path is unserviceable and under repair.
- If a secondary flow path is not possible, build in buffering so the process can continue for a time until repaired.
- Provide for clear, controlled and easy to understand manual intervention in the process.
- Provide checks for human errors during manual intervention, so mistakes are caught before they become serious.
- Make the delineation between the computer and the human absolutely clear and unambiguous, as to who is running the process.
Curt Graeber, Chief Engineer Human Factors Engineering, of Boeing, made the following comments in a Boeing Aeromagazine article.
Appropriate degree of automation.
Boeing flight decks are designed to provide automation to assist, but not replace, the flight crew member responsible for safe operation of the airplane. Flight crew errors typically occur when the crew does not perceive a problem and fails to correct the error in time to prevent the situation from deteriorating. Consequently, Boeing flight decks incorporate intuitive, easy-to-use systems. These systems support instrument displays with visual and tactile motion cues to minimize potential confusion about what functions are automated. In the fly-by-wire 777, visual and tactile motion cues are provided by backdriven controls. These controls reinforce situational awareness and help keep the flight crew fully aware of changes occurring to the airplane’s status and flight path during all phases of automated and manual flight.
Boeing flight decks are designed to provide automation to assist, but not replace, the flight crew member responsible for safe operation of the airplane. Flight crew errors typically occur when the crew does not perceive a problem and fails to correct the error in time to prevent the situation from deteriorating. Consequently, Boeing flight decks incorporate intuitive, easy-to-use systems. These systems support instrument displays with visual and tactile motion cues to minimize potential confusion about what functions are automated. In the fly-by-wire 777, visual and tactile motion cues are provided by backdriven controls. These controls reinforce situational awareness and help keep the flight crew fully aware of changes occurring to the airplane’s status and flight path during all phases of automated and manual flight.
In the A320, I believe the design philosophy was overly ambitious from the beginning. The A320 was the first of it's kind in FBW airliner design, and l believe later designs have learned from the A320 experience.
In Bernd's post #1837 he said,
As to the workings of the thrust levers: it is really terribly simple, and a confusion very unlikely:
In a normal flight you really only need three positions. This flight was no different:
- FLX/MCT (or possibly TOGA in certain conditions) from takeoff to thrust reduction. This gives flexible (or maximum) take-off power and arms autothrust.
- CL throughout the entire flight from thrust reduction to flare. This activates autothrust, previously armed by setting (flexible or maximum) takeoff power.
- IDLE during flare.
In a normal flight you really only need three positions. This flight was no different:
- FLX/MCT (or possibly TOGA in certain conditions) from takeoff to thrust reduction. This gives flexible (or maximum) take-off power and arms autothrust.
- CL throughout the entire flight from thrust reduction to flare. This activates autothrust, previously armed by setting (flexible or maximum) takeoff power.
- IDLE during flare.
From my Six Sigma training and time spent applying it, I have learned that exceptionally low error rates usually only happen in manufacturing environments where the variables can be limited and controlled. In service oriented processes, the variables are usually much larger in number and many are usually beyond control. The human often has to intervene is these cases. It’s much easier to control the variables when manufacturing an airliner, than it is to control the variables when an airliner is used in service.
The landing of an airliner is not always predictable and the human is subject to making an error when performing a repetitive task during landing. Thus I find it hard to believe that the pilots of the TAM A320 were allowed to get into the situation that killed them. Once they deployed thrust reverse on ENG1 while leaving ENG2 thrust lever in the CLB detent during touchdown, the accident had already happened. Correct me if I’m wrong, but doesn’t the 737 for example prevent such an occurrence (with a lockout), by not allowing the pilot to put an engine in reverse if the other throttle lever is not in idle? This preserves the go-around option which was lost with the TAM A320.
Who has the airplane in regards to speed control? Once the pilot selected reverse thrust for ENG1 in those conditions, who had control over the aircraft’s speed on the ground? Because the airplane allowed the asymmetric reverser deployment (automation or even mechanically not watching over the pilot), the ground spoilers and auto brakes did not respond correctly to these conditions. Yes, these systems responded to their control logic, but that was all they could do, as they could not go beyond their control logic to assist in this particular set of circumstances. Of course there was no override of the ground spoilers available to the pilots (overly ambitious automation design that assumed it would never be needed), which I’m sure they would have used (if available) due to the fact that they cycled the arming of the spoilers to try and stop. They had manual brakes, but no manual spoilers, thus who had control over the speed of the airplane on the ground was ambiguous.
I think the H2F3 software modification is helpful, but less than a satisfactory solution. I think it better to prevent the pilots from entering into this single TR thrust lever coffin corner, than to warn them about it once they’re in it already.
I could go on, but will stop here as I have to go.
Join Date: Jul 2007
Location: Germany
Posts: 556
Likes: 0
Received 0 Likes
on
0 Posts
Flight Safety,
thank you for your thoughts on the matter.
Just a few short remarks (as you probably expected
)
Yes.
I'd really like to know what you base this assertion on. It was very ambitious at its time, no doubt. But overly? Why? They managed to pull it off, didn't they?
And despite good efforts, no-one has yet shown that its systems cause problems absent in other models.
Later designs like the the A330/340/380? Look at the cockpits of those. They look and work just like an A320, except that the screens are bigger, and they have taxi cameras. (Reverse is different, but I'm not aware of cross-engine mechanical interlocks.)
(my emphasis.)
With pleasure.
Assuming Boeing 737 and B747-400 are similar, the FDR graphs of the Tahiti incident show clearly, that there can be no interlock between thrust levers on the 744. Reverse was selected on engines 2 through 4, while engine 1 (and, by logic of its back-driven mechanism, also its thrust lever) was at high forward power (>100% N1).
(Regarding your Boeing quote: What Boeing people say in a Boeing magazine about Boeing aircraft is obvious marketing, similar things can certainly be found about Airbus aircraft in Airbus publications.)
The Airbus design philosophy has, I think, been summarised by Dani (and others): The aircraft does nothing by itself; there is no doubt about who is in control.
This is quite in-line with your design principles. It supports in routine tasks, but leaves all decisions to the crew.
Bernd
thank you for your thoughts on the matter.
Just a few short remarks (as you probably expected
)
Because the human mind is more creative and an infinitely better problem solver, it will always be the smartest computer in a process. The computer however can assist the human in its main weakness, which is making mistakes when performing routine repetitive tasks. The strength of each can accommodate the other's weakness, as they are very complimentary.
In the A320, I believe the design philosophy was overly ambitious from the beginning.
And despite good efforts, no-one has yet shown that its systems cause problems absent in other models.
The A320 was the first of it's kind in FBW airliner design, and l believe later designs have learned from the A320 experience.
Correct me if I’m wrong, but doesn’t the 737 for example prevent such an occurrence (with a lockout), by not allowing the pilot to put an engine in reverse if the other throttle lever is not in idle?
With pleasure.
Assuming Boeing 737 and B747-400 are similar, the FDR graphs of the Tahiti incident show clearly, that there can be no interlock between thrust levers on the 744. Reverse was selected on engines 2 through 4, while engine 1 (and, by logic of its back-driven mechanism, also its thrust lever) was at high forward power (>100% N1).
(Regarding your Boeing quote: What Boeing people say in a Boeing magazine about Boeing aircraft is obvious marketing, similar things can certainly be found about Airbus aircraft in Airbus publications.)
The Airbus design philosophy has, I think, been summarised by Dani (and others): The aircraft does nothing by itself; there is no doubt about who is in control.
This is quite in-line with your design principles. It supports in routine tasks, but leaves all decisions to the crew.
Bernd
Guest
Posts: n/a
PJ2,
First of all thanks for your post.
I asked that question about the correlation between EPR and actual thrust in KN in order to get an aproximate value for the thrust yielded by engine n. 2 (the one with the TL above idle) in the accident in Congonhas and compare it with the thrust yielded by the correspondent engine in the TransAsia accident to get some hint about brake efficiency in both cases.
1 - TAM PR-MBK: 1.18 EPR; (800m above msl)
2 - TransAsia: 1.08 EPR; (aprox. 0m msl I guess)
Probably the thrust in KN varies with aircraft speed and altitude. The drag changes as well. PR-MBK was heavier.
I had already found that explanation from Nasa but I think there is some data still missing to do the math (ETR for instance).
Within a certain speed the investigation team could test it with an actual A320 in the runway (GRU for instance - a long runway). Of course actual thrust would be "distorted" by drag but naturally the same happened with the PR-MBK and also in TransAsia accident.
Maybe a simulator could help. Of course the simulated event would involve one single engine at 1.18 and then at 1.08 EPR without braking and from lower to higher speed and get the respective acceleration(s)
First of all thanks for your post.
I asked that question about the correlation between EPR and actual thrust in KN in order to get an aproximate value for the thrust yielded by engine n. 2 (the one with the TL above idle) in the accident in Congonhas and compare it with the thrust yielded by the correspondent engine in the TransAsia accident to get some hint about brake efficiency in both cases.
1 - TAM PR-MBK: 1.18 EPR; (800m above msl)
2 - TransAsia: 1.08 EPR; (aprox. 0m msl I guess)
Probably the thrust in KN varies with aircraft speed and altitude. The drag changes as well. PR-MBK was heavier.
I had already found that explanation from Nasa but I think there is some data still missing to do the math (ETR for instance).
Within a certain speed the investigation team could test it with an actual A320 in the runway (GRU for instance - a long runway). Of course actual thrust would be "distorted" by drag but naturally the same happened with the PR-MBK and also in TransAsia accident.
Maybe a simulator could help. Of course the simulated event would involve one single engine at 1.18 and then at 1.08 EPR without braking and from lower to higher speed and get the respective acceleration(s)
Join Date: May 2000
Location: Glorious West Sussex
Age: 76
Posts: 1,020
Likes: 0
Received 0 Likes
on
0 Posts
PJ2 wrote
The FF is only sampled every 4 seconds - the EPR every second.
FF at 48:25.5 corresponds with an accelerating EPR of 1.13
FF at 48:29.5 corresponds with the final stable EPR of 1.18
FF appears virtually constant because of the sampling rate - but the EPR and ENG VIB give a better picture.
Cheers, TP
In reference to N1, it would have been nice to have had the parameter in the TAM traces so we could see what the N1 was doing during the EPR 1.3 "bloom" as reverse was selected. The fuel flow doesn't change so we could assume neither did the N1 and the "bloom" may mean less than first appears.
FF at 48:25.5 corresponds with an accelerating EPR of 1.13
FF at 48:29.5 corresponds with the final stable EPR of 1.18
FF appears virtually constant because of the sampling rate - but the EPR and ENG VIB give a better picture.
Cheers, TP
Paxing All Over The World
Non-pilot speaking.
On the matter of FDR sampling - and please say if this should be asked elsewhere rather in the thread that has prompted the question.
In the past, FDR units were limited by recording medium in particular. Now that rugged, high capacity data storage is readily available, is there a move to change the sampling rates?
For example, during taxi and cruise, the conventional sampling rates might be sufficient but, during departure and approach, the sampling rates could be doubled? A two second interval reduces to one second and a one second reduces to half a second? The triggers for the change in sampling rates should be fairly simple to define.
I realise, of course, that there would be an enormous time delay from any manufacturer offering this feature and it becoming common, due to the long tail of installed equipment.
The new FDRs could have the capacity for flight deck cameras to be included, the investigation of this event would really benefit from camera evidence.
On the matter of FDR sampling - and please say if this should be asked elsewhere rather in the thread that has prompted the question.
In the past, FDR units were limited by recording medium in particular. Now that rugged, high capacity data storage is readily available, is there a move to change the sampling rates?
For example, during taxi and cruise, the conventional sampling rates might be sufficient but, during departure and approach, the sampling rates could be doubled? A two second interval reduces to one second and a one second reduces to half a second? The triggers for the change in sampling rates should be fairly simple to define.
I realise, of course, that there would be an enormous time delay from any manufacturer offering this feature and it becoming common, due to the long tail of installed equipment.
The new FDRs could have the capacity for flight deck cameras to be included, the investigation of this event would really benefit from camera evidence.
Join Date: Jul 2007
Location: Germany
Posts: 556
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by PJ2
In response to your questions, EPR, like hundreds of other parameters are indeed recorded on DFDRs as would N1, N2, (N3), fuel flow, EGT, N1/N2/(N3) vibration levels etc. It would be part of a legal (certified/required) parameter set.
Interestingly enough, Airbus stated in the appendix of the Taipei-Sungshan-Overrun, that N1 was not recorded on that particular model. This surprised me, since IAE-equipped A320s have three "quasi-analog" circular gauges for engine parameters, EPR, EGT, N1 (and a smaller one for N2). If N1 is deemed important enough to show on the primary engine display, even if the "main" power parameter is EPR, why not record it?
Originally Posted by Appendix to GE536-Overrun-Report
3/ Thrust in relation with EPR
We cannot provide this information as in order to accurately compute this we would require the N1 for the Engine 1 in reverse, and this is not recorded, and also there would be some time spent in unusual transitory phases between REV MAX and REV IDLE. For the Engine 2 at 1.08 EPR the thrust would be of the order of 3000 DaN. (Please see NOTE to previous reply).
We cannot provide this information as in order to accurately compute this we would require the N1 for the Engine 1 in reverse, and this is not recorded, and also there would be some time spent in unusual transitory phases between REV MAX and REV IDLE. For the Engine 2 at 1.08 EPR the thrust would be of the order of 3000 DaN. (Please see NOTE to previous reply).
Bernd
Re,
Thanks TP - (the VIBs are also ev. 4 seconds).
Typical FDA/FOQA QAR installations record FF at once-per-second, which speaks more to the need for finer granularity for DFDRs.
That said, it would be nice to have had the N1's here - they're there on the DFDR I'm sure, but don't know why they're not included in these traces.
but the EPR and ENG VIB give a better picture.
Typical FDA/FOQA QAR installations record FF at once-per-second, which speaks more to the need for finer granularity for DFDRs.
That said, it would be nice to have had the N1's here - they're there on the DFDR I'm sure, but don't know why they're not included in these traces.
glob99;
With the forebearance of the forum admins, I would like to take a diversion into dataframes for understanding. Perhaps this may assist others as it will me. The primary goal is to understand this sufficiently to be able to appreciate how sample rates represent realities in the interpretation of flight data for the purposes of determining "what happened". How close can we get and what are the pitfalls?
Not formally educated in physics, I'm on the edge of my knowledge but I wonder if the Nyquist Theorem (rate) would apply to flight data?
I am very prepared to learn here as I initially thought that both fft and the Nyquist theorem could be applied usefully to flight data sampling because they are signals but right now I sense not unless a less formal interpretation is being offered.
The reason I ask is, the "signal" of a parameter while still a recorded voltage, is not a sine wave but a discrete "on-off", a rate-per-second, or a position (degrees), the "frequency"of which is determined not by the signal or the recording equipment but by a fixed data-frame. Flight data isn't a frequency but is a voltage represented by a fixed data state. Flight data (engineering format) cannot be displayed on an oscilliscope for example. However, the source of flight data may possibly be so displayed and that is where the Nyquist theorem may have relevance.
I'm not sure where the term "frequency", and "sampling rate" should be applied. It seems to me that they are in circular reference to one another in flight data, the dataframe supplying, by pure frame design (4x512) both frequency and sample rate. That said, the potential for far higher sampling rates is there and only restricted by the design of the dataframe itself, at least from my point of view all of which goes to prove that a tiny bit of knowledge is a dangerous thing!
Anyway, I understand the inherent inaccuracies behind the notion of "using a yardstick to measure a foot" but I'm not sure there isn't more to your suggestion than first meets the untrained eye?
We measure 'g' at eight times a second, most other parameters at four, two or once per second and those which do not change rapidly over time, once every two or four seconds.
A poster has suggested that recording be "enriched" during the critical phases of flight. I would agree but that represents technical problems in terms of dataframe and software design, not insurmountable but probably more easily resolved in increasing the dataframe to 4x1024 for instance.
Ideally, 29.96 frames-per-second for all parameters (with a search capability equal to such a task!), would be wonderful and maybe we'll see that as cheap memory and processor speeds permit.
In the meantime, those who do data work (and I suspect you're among them), know that estimating the values in between cannot/should not be done. It's a fascinating rabbit-trail and I hope that the admins permit the diversion.
With the forebearance of the forum admins, I would like to take a diversion into dataframes for understanding. Perhaps this may assist others as it will me. The primary goal is to understand this sufficiently to be able to appreciate how sample rates represent realities in the interpretation of flight data for the purposes of determining "what happened". How close can we get and what are the pitfalls?
Not formally educated in physics, I'm on the edge of my knowledge but I wonder if the Nyquist Theorem (rate) would apply to flight data?
I am very prepared to learn here as I initially thought that both fft and the Nyquist theorem could be applied usefully to flight data sampling because they are signals but right now I sense not unless a less formal interpretation is being offered.
The reason I ask is, the "signal" of a parameter while still a recorded voltage, is not a sine wave but a discrete "on-off", a rate-per-second, or a position (degrees), the "frequency"of which is determined not by the signal or the recording equipment but by a fixed data-frame. Flight data isn't a frequency but is a voltage represented by a fixed data state. Flight data (engineering format) cannot be displayed on an oscilliscope for example. However, the source of flight data may possibly be so displayed and that is where the Nyquist theorem may have relevance.
I'm not sure where the term "frequency", and "sampling rate" should be applied. It seems to me that they are in circular reference to one another in flight data, the dataframe supplying, by pure frame design (4x512) both frequency and sample rate. That said, the potential for far higher sampling rates is there and only restricted by the design of the dataframe itself, at least from my point of view all of which goes to prove that a tiny bit of knowledge is a dangerous thing!
Anyway, I understand the inherent inaccuracies behind the notion of "using a yardstick to measure a foot" but I'm not sure there isn't more to your suggestion than first meets the untrained eye?
We measure 'g' at eight times a second, most other parameters at four, two or once per second and those which do not change rapidly over time, once every two or four seconds.
A poster has suggested that recording be "enriched" during the critical phases of flight. I would agree but that represents technical problems in terms of dataframe and software design, not insurmountable but probably more easily resolved in increasing the dataframe to 4x1024 for instance.
Ideally, 29.96 frames-per-second for all parameters (with a search capability equal to such a task!), would be wonderful and maybe we'll see that as cheap memory and processor speeds permit.
In the meantime, those who do data work (and I suspect you're among them), know that estimating the values in between cannot/should not be done. It's a fascinating rabbit-trail and I hope that the admins permit the diversion.
Join Date: Jul 2007
Location: Germany
Posts: 556
Likes: 0
Received 0 Likes
on
0 Posts
PJ2,
as always a pleasure to read ...
(Maybe this really belongs in another thread ...)
I've been wondering about the choice of sampling rates for different parameters. The Sungshan-Report showed that actual brake pressure was only recorded once every 4 seconds, although during anti-skid-operation it changes rapidly.
glob99 is of course right in saying that if the highest frequency that may be contained in the signal is low enough (half the sampling rate), data can theoretically be reconstructed completely, practically limited by the losses in value-discretisation on a digital recording and other technical and physical phenomena.
For values determined solely by the output signals of a computer, i. e. fuel flow, the position of control surfaces, etc, this frequency is determined by the software design and the processing speed. It can in theory be determined accurately.
Human inputs are a bit different, but given a certain inertia of limbs and controls, one can put reasonable upper limits to that as well.
Outside physical forces on the aircraft, as measured by the acceleration, may contain very high frequencies, especially if a hard object is hit, there is severe turbulence, or simply by a bumpy runway. In this case it is vital that these be sampled at a higher rates, e. g. to determine the exact location of a piece of debris on the runway that caused damage.
The simple on/off switching action (mathematically accurately described by the Heaviside step function) can never be sampled completely accurate, since it contains frequencies up to infinite. A choice of needed accuracy has to be made.
I'm off to SAFECOMP in Nuremberg for the week now,
Bernd
as always a pleasure to read ...
(Maybe this really belongs in another thread ...)
We measure 'g' at eight times a second, most other parameters at four, two or once per second and those which do not change rapidly over time, once every two or four seconds.
glob99 is of course right in saying that if the highest frequency that may be contained in the signal is low enough (half the sampling rate), data can theoretically be reconstructed completely, practically limited by the losses in value-discretisation on a digital recording and other technical and physical phenomena.
For values determined solely by the output signals of a computer, i. e. fuel flow, the position of control surfaces, etc, this frequency is determined by the software design and the processing speed. It can in theory be determined accurately.
Human inputs are a bit different, but given a certain inertia of limbs and controls, one can put reasonable upper limits to that as well.
Outside physical forces on the aircraft, as measured by the acceleration, may contain very high frequencies, especially if a hard object is hit, there is severe turbulence, or simply by a bumpy runway. In this case it is vital that these be sampled at a higher rates, e. g. to determine the exact location of a piece of debris on the runway that caused damage.
The simple on/off switching action (mathematically accurately described by the Heaviside step function) can never be sampled completely accurate, since it contains frequencies up to infinite. A choice of needed accuracy has to be made.
I'm off to SAFECOMP in Nuremberg for the week now,
Bernd
I support PPRuNe
Join Date: Jul 2007
Location: Belo Horizonte, Brazil
Posts: 162
Likes: 0
Received 0 Likes
on
0 Posts
Brazilian pilot flying A320 in China
Subject: Sobre o Airbus
Date: Sat, 15 Sep 200702:36:12 -0500
Aea Galera,
Hi everyone
Como tá todo mundo...?
How are you?
Pois é pessoal, cada vez mais eu me convenço que esse tal de Airbus série 319, 20 e 21 não é um avião de confiança.
Well people, each time I get more convinced that these so called Airbus, series 319, 20 and 21 are not trustworthy planes.
Ai que saudades de voar um Boeing 737... Era o que tava no check-list e acabou!!!
Ah, how I miss flying a Boeing 737...It was what was in the check list and that was all!!!
O Airbus é cheio de pegadinhas que não diz em parte nenhuma dos manuais. Aquilo não é um avião, é um computador com asas!!!
The Airbus is full of tricks that you can´t find anywhere in the manuals. It is not airplane, it is a computer with wings.
Qualquer piloto de 737 pilota um outro 737 de qualquer outra Cia aérea do mundo, já essa bosta desse avião tem 900 mil softwares diferentes e cada avião é diferente do outro.
Any 737 pilot pilots another 737 from any airline in the world, but this sh... of a plane has 900 thousand different softwares and each plane is different from the other.
E esse caso agora da TAM que estão colocando a culpa nos pilotos?
And in this TAM case, are they placing the blame on the pilots?
Acabei de voltar do simulador e numa das panes que treinamos o cabocloreduz as manetes prá pousar, mas ocorre uma pane no sensor da TLA(1)e o Computador acha que o piloto não reduziu as manetes e não te avisa de nada.
I just came out of the simulator and in one of the failures we trained to reduce the TLs to land, but there is a malfuntion in the TLA(1) sensor and the computer believes that the pilot did not reduce the TLs and doesn´t warn you of nothing.
Treinamos isso no simulador e nesse caso tem que cortar imediatamente o motor, só que não tem nenhum alarme ou tempo hábil para identificar e reagir!!!
We trained this in the simulator and in this situation we have to cut the motor immediatelly, but there is no alarm or proper time to identify and react!!!
E o pior de tudo é que o computador manda o motor acelerar prá TOGA(2),cancela spoilers e auto-brakes porque acha que o avião ainda está voando sendo que vc já pousou e está tentando freiar o avião. Você olha a manete e ela está lá em idle!!!
And worse yet the computer orders the motor to accelerate for TOGA(2). Cancels the spoilers and auto-brakes because it believes that the airplane is still flying even though we already landed and are trying to brake the plane. You look at the TL and it is there on Idle.
O caso da TAM já é o quinto no mundo!!!
Tam´s case is the fifth in the world.
A ***** toda é que embora vc tenha todos os comandos manuais, se o tal do fly-by-wire estiver em pane e não te avisar, vc está fodido.
The whole sh... is that although you have all manual commands, if the so called fly-by-wire is failing and is not warning you, you are fuc... out.
E fly-by-wire inclui não só o side-stick, mas tbm os pedais, FREIOS!!!, nose-wheel stering, e todos os comandos de motor!!!
And the fly-by-wire includes not only the side-sticks but also the pedals, BRAKES!!!, nose wheel steering, and all the commands for the motor.
E o VNAV(3) desse avião é a coisa mais burra e retardada que já vi num avião na minha vida!!!
And the VNAV(3) of this plane is the dummiest and retarded thing that I have seen in a plane all my life!!!
Mas aqui tem o dia do Cala-Boca, (28), quando o salário entra direitinho e gordinho...
But here there is that shut your mouth day (28) when the salary come in straigh and fat...
Estou com 650 horas no avião e estou me sentindo um técnico eminformática, não um aviador. Com 650 horas no Boeing eu já estava criando umas peninhas nas asas e sentindo o maior prazer de voar.
I have 650 hours in the plane and I am feeling an expert in computers, not an aviator. With 650 hours in the Boeing I already was having some small feathers in my wings and feeling a great pleasure in flying.
Desculpem o desabafo, mas foi muito frustrante ter estudado pra caralho
Forgive me the catharsis, but it has been frustating studying so much.
Pra fazer esse último simulador e ver que isso não adianta muita coisa em se tratando de voar Airbus.Tirei lá a minha notinha boa, mas não me serve...
To do this last simulator and to see this did not help much insofar as flying Airbus. I had a good grade but did not help...
Mas vamo que vamo full operation...
But we will go for full operation...
O que importa é que a família está bem adaptada e a vida aqui é muito tranquila.
What matters is that the family is well asjusted and life here is tranquil.
Um grande abraço a todos e mandem algumas notícias.
A great embrace. Send me news.
(1) Thrust Lever Angle
(2) Take-off/Go-Around Thrust Setting!
(3) Vertical Navigation Mode.
Date: Sat, 15 Sep 200702:36:12 -0500
Aea Galera,
Hi everyone
Como tá todo mundo...?
How are you?
Pois é pessoal, cada vez mais eu me convenço que esse tal de Airbus série 319, 20 e 21 não é um avião de confiança.
Well people, each time I get more convinced that these so called Airbus, series 319, 20 and 21 are not trustworthy planes.
Ai que saudades de voar um Boeing 737... Era o que tava no check-list e acabou!!!
Ah, how I miss flying a Boeing 737...It was what was in the check list and that was all!!!
O Airbus é cheio de pegadinhas que não diz em parte nenhuma dos manuais. Aquilo não é um avião, é um computador com asas!!!
The Airbus is full of tricks that you can´t find anywhere in the manuals. It is not airplane, it is a computer with wings.
Qualquer piloto de 737 pilota um outro 737 de qualquer outra Cia aérea do mundo, já essa bosta desse avião tem 900 mil softwares diferentes e cada avião é diferente do outro.
Any 737 pilot pilots another 737 from any airline in the world, but this sh... of a plane has 900 thousand different softwares and each plane is different from the other.
E esse caso agora da TAM que estão colocando a culpa nos pilotos?
And in this TAM case, are they placing the blame on the pilots?
Acabei de voltar do simulador e numa das panes que treinamos o cabocloreduz as manetes prá pousar, mas ocorre uma pane no sensor da TLA(1)e o Computador acha que o piloto não reduziu as manetes e não te avisa de nada.
I just came out of the simulator and in one of the failures we trained to reduce the TLs to land, but there is a malfuntion in the TLA(1) sensor and the computer believes that the pilot did not reduce the TLs and doesn´t warn you of nothing.
Treinamos isso no simulador e nesse caso tem que cortar imediatamente o motor, só que não tem nenhum alarme ou tempo hábil para identificar e reagir!!!
We trained this in the simulator and in this situation we have to cut the motor immediatelly, but there is no alarm or proper time to identify and react!!!
E o pior de tudo é que o computador manda o motor acelerar prá TOGA(2),cancela spoilers e auto-brakes porque acha que o avião ainda está voando sendo que vc já pousou e está tentando freiar o avião. Você olha a manete e ela está lá em idle!!!
And worse yet the computer orders the motor to accelerate for TOGA(2). Cancels the spoilers and auto-brakes because it believes that the airplane is still flying even though we already landed and are trying to brake the plane. You look at the TL and it is there on Idle.
O caso da TAM já é o quinto no mundo!!!
Tam´s case is the fifth in the world.
A ***** toda é que embora vc tenha todos os comandos manuais, se o tal do fly-by-wire estiver em pane e não te avisar, vc está fodido.
The whole sh... is that although you have all manual commands, if the so called fly-by-wire is failing and is not warning you, you are fuc... out.
E fly-by-wire inclui não só o side-stick, mas tbm os pedais, FREIOS!!!, nose-wheel stering, e todos os comandos de motor!!!
And the fly-by-wire includes not only the side-sticks but also the pedals, BRAKES!!!, nose wheel steering, and all the commands for the motor.
E o VNAV(3) desse avião é a coisa mais burra e retardada que já vi num avião na minha vida!!!
And the VNAV(3) of this plane is the dummiest and retarded thing that I have seen in a plane all my life!!!
Mas aqui tem o dia do Cala-Boca, (28), quando o salário entra direitinho e gordinho...
But here there is that shut your mouth day (28) when the salary come in straigh and fat...
Estou com 650 horas no avião e estou me sentindo um técnico eminformática, não um aviador. Com 650 horas no Boeing eu já estava criando umas peninhas nas asas e sentindo o maior prazer de voar.
I have 650 hours in the plane and I am feeling an expert in computers, not an aviator. With 650 hours in the Boeing I already was having some small feathers in my wings and feeling a great pleasure in flying.
Desculpem o desabafo, mas foi muito frustrante ter estudado pra caralho
Forgive me the catharsis, but it has been frustating studying so much.
Pra fazer esse último simulador e ver que isso não adianta muita coisa em se tratando de voar Airbus.Tirei lá a minha notinha boa, mas não me serve...
To do this last simulator and to see this did not help much insofar as flying Airbus. I had a good grade but did not help...
Mas vamo que vamo full operation...
But we will go for full operation...
O que importa é que a família está bem adaptada e a vida aqui é muito tranquila.
What matters is that the family is well asjusted and life here is tranquil.
Um grande abraço a todos e mandem algumas notícias.
A great embrace. Send me news.
(1) Thrust Lever Angle
(2) Take-off/Go-Around Thrust Setting!
(3) Vertical Navigation Mode.
Last edited by marciovp; 20th Sep 2007 at 00:19. Reason: Typo
Guest
Posts: n/a
Pois é pessoal, cada vez mais eu me convenço que esse tal de Airbus série 319, 20 e 21 não é um avião de confiança.
Well people, each time I get more convinced that these so called Airbus, series 319, 20 and 21 are not trustworthy planes.
Well people, each time I get more convinced that these so called Airbus, series 319, 20 and 21 are not trustworthy planes.
Are you ready to be heavily...
PPRuNe supporter
Join Date: Dec 2003
Location: Planet Earth
Posts: 1,677
Likes: 0
Received 0 Likes
on
0 Posts
Well people, each time I get more convinced that these so called Airbus, series 319, 20 and 21 are not trustworthy planes
Join Date: Jun 2005
Location: Citizen of the World
Posts: 174
Likes: 0
Received 0 Likes
on
0 Posts
Bernd and Flight Safety.
Quote: "The Airbus design philosophy has, I think, been summarised by Dani (and others): The aircraft does nothing by itself; there is no doubt about who is in control."
I beg to differ with both of you on this point and with Dani who seems to be happy to jump to various conclusions both in this thread and in the Phuket accident thread and to then ignore these shortcomings when pointed out by those who are better-informed. Oh to be so certain!
The A320 has all sorts of flight envelope protections that will cut in regardless of pilot inputs, just to give a simple example. It does lots of things by itself - often despite the pilot's efforts.
However as I pointed out before, I have watched pilots struggle to understand the automatics on this a/c and also on the 737 NG. I have no doubt in my mind that the 737 is an easier aircraft for pilots to convert to and not just because it doesn't have the advanced design of the 320. It is simply more intuitive and therefore easier.
I don't know any instructor who hasn't watched pilots in the sim and aircraft struggle to understand what was going on at various stages of initial training but more importantly at recurrent training sessions. Some pilots never fully get to grips with the logic of some of the systems on this aircraft and that, for me as an instructor, is worrying. Any TRE will tell you of the confusion that is regularly created by the non-normal procedures for Flap/Slat problems, for example. And the FMGS must have been designed by a cretin, so difficult is it for pilots to remember which button to push until it is memorised. That is not good design.
The fact is, that this is a very challenging aircraft to operate when things go badly wrong. The ECAM checklists are not adequate for some failures and pilots end up switching from ECAM to paper and back to ECAM. There is something wrong with a design that is not intuitive for a pilot to operate. For all its faults (and it has lots), the 737 is a much more pilot-friendly aircraft than the 320. Please don't misunderstand my point, I love operating this aircraft (A320) but then I've had to force myself to really attempt to understand it. I do not enjoy watching good pilots struggle with its logic (or lack thereof).
It is because of these observed difficulties that I have great sympathy with the crew on the fateful night. The confusion created (regardless of whether it was created by their own error or not) by the lack of deceleration must have been every pilot's worst nightmare on a short, probably slippery runway.
The basic facts appear to be fairly clear as annunciated by BOAC. What intrigues me is
1. Why would any pilot leave the Thrust lever at CLB
2. Why does the availability of autobrake depend on spoilers
3. Why was this aircraft designed in such a manner that if the automatic deployment of spoilers fails for whatever reason, manual spoiler control is not available to the pilot when he most needs it - on the landing roll in limiting conditions.
Of course it is likely that the investigation will find pilot error (hardly in question if the TL was actually left in climb detent which appears to be the case). However, I wouldn't hold my breath about them addressing the human factors of man/machine interface which I believe probably played a (significant?) part in the error chain.
To all of you thank you most sincerely for your efforts on this thread. I, for one, have learned much from your contributions.
Quote: "The Airbus design philosophy has, I think, been summarised by Dani (and others): The aircraft does nothing by itself; there is no doubt about who is in control."
I beg to differ with both of you on this point and with Dani who seems to be happy to jump to various conclusions both in this thread and in the Phuket accident thread and to then ignore these shortcomings when pointed out by those who are better-informed. Oh to be so certain!
The A320 has all sorts of flight envelope protections that will cut in regardless of pilot inputs, just to give a simple example. It does lots of things by itself - often despite the pilot's efforts.
However as I pointed out before, I have watched pilots struggle to understand the automatics on this a/c and also on the 737 NG. I have no doubt in my mind that the 737 is an easier aircraft for pilots to convert to and not just because it doesn't have the advanced design of the 320. It is simply more intuitive and therefore easier.
I don't know any instructor who hasn't watched pilots in the sim and aircraft struggle to understand what was going on at various stages of initial training but more importantly at recurrent training sessions. Some pilots never fully get to grips with the logic of some of the systems on this aircraft and that, for me as an instructor, is worrying. Any TRE will tell you of the confusion that is regularly created by the non-normal procedures for Flap/Slat problems, for example. And the FMGS must have been designed by a cretin, so difficult is it for pilots to remember which button to push until it is memorised. That is not good design.
The fact is, that this is a very challenging aircraft to operate when things go badly wrong. The ECAM checklists are not adequate for some failures and pilots end up switching from ECAM to paper and back to ECAM. There is something wrong with a design that is not intuitive for a pilot to operate. For all its faults (and it has lots), the 737 is a much more pilot-friendly aircraft than the 320. Please don't misunderstand my point, I love operating this aircraft (A320) but then I've had to force myself to really attempt to understand it. I do not enjoy watching good pilots struggle with its logic (or lack thereof).
It is because of these observed difficulties that I have great sympathy with the crew on the fateful night. The confusion created (regardless of whether it was created by their own error or not) by the lack of deceleration must have been every pilot's worst nightmare on a short, probably slippery runway.
The basic facts appear to be fairly clear as annunciated by BOAC. What intrigues me is
1. Why would any pilot leave the Thrust lever at CLB
2. Why does the availability of autobrake depend on spoilers
3. Why was this aircraft designed in such a manner that if the automatic deployment of spoilers fails for whatever reason, manual spoiler control is not available to the pilot when he most needs it - on the landing roll in limiting conditions.
Of course it is likely that the investigation will find pilot error (hardly in question if the TL was actually left in climb detent which appears to be the case). However, I wouldn't hold my breath about them addressing the human factors of man/machine interface which I believe probably played a (significant?) part in the error chain.
To all of you thank you most sincerely for your efforts on this thread. I, for one, have learned much from your contributions.